You are not logged in.
Check out the dashboard, the most probably you have issue on your file. So [[LargestArea]] is 0, so you will have invalid expression. (2/[[LargestArea]] => 2/0)
I would suggest handle [[LargestArea]] with more care. (([[LargestArea]]<1)*0+1))
As I said before, the notation you came up with just completely eludes me for some reason. I'll confess, I copied and pasted directly out of the spreadsheet linked above, per the instructions there.
To clarify, the expression is returning zero somewhere? And error in my file? My workflow is to create a model in Rhino, export a .ply to Meshmixer to add support, export an STL to Asiga Stomp for slicing, then manually run through the SLC file before allowing it to be automatically checked in Sleece. If the SLC came out right, I'll upload that to NanoDLP. A problem with my file would imply NanoDLP errored somewhere during the conversion process, or I missed something completely when checking the file in Sleece.
Or did I misinterpret the whole statement?
{Sorry if that's long winded or nit-picky, you wrote the software and I'd like to learn. }
Let me know how your results turn out, I'm happy someone else was able to get some use from my research.
Apparently I did something wrong, cause NanoDLP has decided that the formula isn't valid. It glitched out, and basically decided to cure each layer for the layer number, in seconds. (i.e. the 512th layer is cured for 512 seconds, the 600th layer is cured for 600 seconds).
The formula your spreadsheet kicked out is:
{(([[LayerNumber]]<10)*90)+(([[LayerNumber]]<104)*45)+((2/[[LargestArea]])<9)*9+((2/[[LargestArea]])>16.2)*16.2+((2/[[LargestArea]])>9)*((2/[[LargestArea]]))*((2/[[LargestArea]])<16.2)}
DLprinter -
What are you using for support generation and plating? Your prints look amazing, and they're support VERY well. How'd you accomplish that?
You sir, are a god. I'll be erecting shrines and idols in your honor.
....
New feature also accepts comma separated cure times. For each cure time it renders a pillar on the plate.
Our new display module toggle pillars based on their cure time during calibration.That means if you need to find out a correct cure time for your resin you do not need to print a plate with different cure times. You can print each pillar with different cure time and find out best possible cure time for your resin in one go.
...
How exactly does this work? I asked about resin calibration awhike back, and you told me that you had no advice. I need to find the correct cure time for a pillar 0.5mm x 0.5mm. Is that what this tool is for? If so, how do I set that up?
@jcarletto27
Any chance I could enlist your help figuring out a dynamic cure formula? Or could you post a guide on understanding it? I'm having some real trouble wrapping my head around it, but I already made a thread about it here.
I've got a print I need to get to come out for a customer, so I'm stressing about it a bit. Any help I can get is much appreciated.
We already have total area per layer and largest area per layer as variable on gcode box.
I meant how to find the total area of a layer so that I could work out a formula for dynamic cure time. I was looking to see what the largest versus smallest slice size was in a given model. I can't figure out exactly how the dynamic cure notation works.
I need a formula that is basically:
( [cure time] = [standard cure time] / [total layer surface area] )
But also doesn't allow the cure time to be any less than the standard cure time. I used the new mask creation feature to normalize the UV exposure across my whole build plate, but now my new standard cure time doesn't work as expected.
The standard cure time in my set up will cure a large layer just fine, but won't do jack crap for smaller (read jewelry prongs or bridgework) features. In fact, it's not enough to get layers to adhere correctly or to even form.
So.... suggestions?
Found it, it's the Area command in Rhino after turning a given slice into planar surfaces.
Still working on figuring out the rest.
How would I go about determining the area of a given layer?
I need to make a dynamic cure formula, but I can't figure out how. Obviously the smaller the area the longer the cure time, but where / how do I figure out the area of a given slice? Or how do I figure out the cure time to area ratio or what have you.
Any advice?
If anyone wants or needs it, I modified some existing code from here. I used this same set up with the arduino, LCD shield, and ML8511 sensor, but refactored the code to be more-real time. I noticed that the static measurements weren't really useful for the way that NanoDLP wants to generate its mask, so I changed it to be a running average. The code take 6 readings off the sensor and averages them, then updates the display. When you're generating your mask, you can leave the sensor in the "box" you're measuring, and the longer it's there, the truer your average will be. The lowest consistent reading I got on my printer was a little over 2, so I dialed everything in to be within .05 of that.
I don't think it's good code (like at all), but it does work, so I hope it helps someone.
#include <LiquidCrystal.h>
//Pin assignments for SainSmart LCD Keypad Shield
LiquidCrystal lcd(8, 9, 4, 5, 6, 7);
//Hardware pin definitions
int UVOUT = A1; //Output from the sensor
int REF_3V3 = A2; //3.3V power on the Arduino board
float UV = 0; //UV sensor reading in mW/cm2
int UVRead = 0;
int button = A0;
int buttonRead = 0;
bool firstRun = 0;
float reading[] = {0,0,0,0,0,0};
void setup()
{
lcd.begin(16, 2);
Serial.begin(9600);
pinMode(button, INPUT);
pinMode(UVOUT, INPUT);
pinMode(REF_3V3, INPUT);
}
void loop()
{
int x = 0;
while (x < 7){
int uvLevel = averageAnalogRead(UVOUT);
int refLevel = averageAnalogRead(REF_3V3);
//Use the 3.3V power pin as a reference to get a very accurate output value from sensor
float outputVoltage = 3.3 / refLevel * uvLevel;
float UV = mapfloat(outputVoltage, 0.99, 2.8, 0.0, 15.0); //Convert the voltage to a UV intensity level
reading[x] = UV;
x++;
}
float UVaverage = ( (reading[0] + reading[1] + reading[2] + reading[3] + reading[4] + reading[5]) / 6);
lcd.clear();
lcd.print("UV Reading: ");
lcd.print(UVaverage);
lcd.setCursor(0, 1);
delay(1000);
x = 0;
}
//Takes an average of readings on a given pin
//Returns the average
int averageAnalogRead(int pinToRead)
{
int numberOfReadings = 75;
unsigned int runningValue = 0;
for(int x = 0 ; x < numberOfReadings ; x++)
runningValue += analogRead(pinToRead);
runningValue /= numberOfReadings;
return(runningValue);
}
float mapfloat(float x, float in_min, float in_max, float out_min, float out_max)
{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
I think you can do it easily by editing line 304 on main.js
Will that be permanant? Or will I need to redo it every update?
Is there anyway that the ETA during a print could be displayed in 12-hour format, instead of 24?
Just a small thing, for personal preference.
Any chance of a public beta? Or a private beta? Or a one off alpha?
I'm really jonesing for a better support generator than what's available. I'd engage in morally questionable behavior in exchange for an alternative, even just to play with.
backXslash
sorry man , but you spend time for nothing .
believe me as man who create the first 5-axis cnc for jewelry wax mill in the world
Can't say my time was wasted, after all, it was my time to spend. Nice that you've got a wax mill I suppose though... good for you? The ... is with you people telling me that encoder support is a bad idea or a waste of time? The ... do you care? It's my time, I think it's a worthy pursuit, and even if you don't happen to use it with NanoDLP, it'll probably end up being a useful feature to someone at a later date.
Jesus christ you entitled ...
End rant, I suppose, and thank you Shahin for your patience and support.
Here are some of mine, for funsies
I will happy to try it at WIP version , let me know please when it possible
Second. I'd love to try it.
I can make it ready until the end of next week. How is your progress on the hardware side?
Stalled at the moment, I haven't had a chance to sit and work on it. I'll try to get it to the top of my list again here shortly. The real world has intruded a bit recently.
Hello there.how can i buy one of those vivitek DH558 s?
i really have no idea where to buy one, can you assist please?
and do you have any photos of washers you have used and a summary how did you do that?
The projector is available here. As for the washers, they're just standard M3 washers available wherever you bought the M3 bolts. Really I didn't like the way the washers affected the edge focus, so I got some 1.5mm thick aluminum plates and machined spacer plates so that the entire assembly is maintained as lightproof, just longer.
nanodlp have written in go (golang) with some C and ASM.
I came up with following scenario.
We have USB (serial) encoder. (i2c will be more suitable I am not sure how hard will be implementation on your side)
The encoder needs to support two commandsPOS - current click counter value ZERO - reset counter
On nanodlp side we will have two new configurations.
Click size i2c or serial address for encoder
For direct control:
Before each movement zero command will be sent. After movement position will be requested and if needed another movement will be sent based on reported position
For RAMPS two new keywords will be supported which will be usable on gcode boxes.
[[EncPos]]; in mm [[EncZero]]
Will it be enough?
Sold. I'll get it done as soon as I can!
Current spec looks very good. I have to find a way to support it on both direct control and RAMPS method.
Are you going to wire it directly to nanodlp?
I hate to be a smartass, so if I'm coming off that way, I apologize in advance, but I'll wire it however you tell me to wire it. I'll work this weekend / next week on it, both as a standalone board as well as seeing what I can accomplish with the RPi's GPIO's alone and I guess we can go from there.
I'm a functional programmer, not a good one, by which I mean I'll get the job done and it'll work, but it may not be pretty or best practices. I'm more familiar with C / C++, but I have passing familiarity with Python, Java, Ruby, Perl, Bash, and whatever flavor of JS you want to write Node.JS apps in.
What's NanoDLP actually written in so maybe I can start with that? Otherwise we'll probably end up having to port Python code.
Well, I'm offering to build and code it to your specifications. More than that, you provided NanoDLP to us, it wouldn't be very fitting for me to not reciprocate.
Honestly, I'm trying to make this a core feature of NanoDLP, because I really do think it'll make axis use and calibration easier and more reliable and repeatable for everyone (or at least everyone who chooses to use an encoder enabled axis).
So... you tell me what's best / easiest for NanoDLP
I found this, and think it'd be really nice to be able to watch my printer in real time, but I may be the only one.
Am I alone here?
Actually, my current code and board would cost less than $40 all in for the sensor and board and strip.
At the moment, the board accepts a list of commands:
- ZERO: homes or zeros the position of the sensor (I recommend doing this at the "top" or starting point of your build, so that the count is accurate, but it's there so you can decide)
- POS: responds with the current position of the axis expressed either as a number of clicks or a float equal to the mm distance traveled
- SEEK: this will move the axis in one full step increment until it reaches the requested position (Be aware, this is currently in clicks not mm, I need to fix that)
- STEP: this simply moves the axis by one full step increment (useful for determining the step to click count of your axis)
All communication is over USB serial interface, and is just shockingly smooth and accurate (which I wasn't expecting because let's be honest, the code is shit.)
How would you like me to proceed so that the project can be better integrated with NanoDLP?
If GPIO is going to be main interface, unfortunately OS based software could not keep up with counting job very well. In high speed movements 0.015mm resolution will be lots of pulses per second.
Even if we could get number of clicks through board itself, without any direction or other info. It will be enough to achieve high accuracy.
Well, number of clicks is 100% already done with my current code.
It's a... quadrature encoder? The board takes 5v, and has three channels, A B and index. Index is pulled logic high on every state change, A and B are 90 degrees out of phase, so you can use that to determine direction.
Two great eresources I used are here and here.
Really all you need is two GPIO pins, and allow NanoDLP to count clicks. Provide drop downs for which GPIOs the encoder is connected to, and then allow the user to specify the distance per click of the encoder strip, and the rest is just a simple count. It's all in the (hella alpha) example code I linked.