You are not logged in.
Hi Im currently using build 1357 and dont see the export option in setup.tools ?
do i need a different version ?
Thanks
I could do the Dutch translation if needed
Good news and bad news :-) Bad news = im no expert but learning through research ! Good news is i have a few ideas. To start with take a look at this video which i believe shows a similar setup to what you are trying to achieve >> https://www.youtube.com/watch?v=osoOQjE … yF&index=8
The video at least confirms our previous logic that down = "down" the model and should actually move the platform up in the resin vat.
From what i can see you should try changing your syscall calc for movement from Layer position to Layer thickness so>> G1 Z{[[LayerThickness]]-[[ZLiftDistance]]}
You may need to change the "-" to "+"
You might also want to control the speed by adding the F variable at the end... see below
Example on my KLD LED 1260 " bottom up" printer i have in the "after each layer" section
M107 ; Turns off the LED light source
G1 Z[[ZLiftDistance]] F200 ; Lift printhead out of resin at F speed
G1 Z{[[LayerThickness]]-[[ZLiftDistance]]} F200 ; move printhead back into resin at Fspeed and by the layer thickness minus the lift distance ( creating a negative Z movement)
[[Delay3]] ; wait for resin to settle before printing next layer
Hope this helps
anybody willing to share a profile for the KLD LED 1260 - YHD 101 please ?
So I just got mine working - at least the calibration screen!
Steps to find your LCD timing:
tvservice -d edid.dat edidparser edid.dat |grep 1440 |sort -uShould give you something like:
HDMI:EDID failed to find a matching detail format for 1440x2560p hfp:60 hs:10 hbp:35 vfp:4 vs:2 vbp:2 pixel clock:198 MHz HDMI:EDID found unknown detail timing format: 1440x2560p hfp:60 hs:10 hbp:35 vfp:4 vs:2 vbp:2 pixel clock:198 MHz HDMI:EDID guessing the format to be 1440x2560p @50 HzThen you know your timings and can set up /boot/config.txt
#Use HDMI hdmi_force_hotplug=1 #define mode 87 hdmi_timings=1440 0 60 10 35 2560 0 4 2 2 0 0 0 50 0 198000000 0 #force mode hdmi_group=2 hdmi_mode=87 hdmi_pixel_freq_limit=500000000 hvs_priority=0x32ff max_framebuffer_width=1440 max_framebuffer_height=2560 framebuffer_width=1440 framebuffer_height=2560 framebuffer_depth=24 framebuffer_ignore_alpha=1 config_hdmi_boost=4 gpu_mem=192Now... what should the printer settings be for timing!
Did you get it working ? Would you please share your printer settings ?
thanks
Send the gcode command >> G92 Z0 which tells the printer its in the home/ start position
Youre welcome. Glad it worked out
Always tricky when i haven't any experience with top down printing. What sheild are you using. Im intrigued by your statement " i have my shield set to Zero at Bottom" I presume you mean the bottom of your vat?? and this is just to prevent the build platform trying to lower beyond the bottom of the vat ??
It can all get quite confusing with the actual direction of the stepper ( wiring), firmware stepper direction and firmware home at min or max as well as homing direction.
Option 1 From your recent post in the "After each layer section" first line i would try changing the "+" to "-"
so >>> G1 Z{[[LayerPosition]]-[[ZLiftDistance]]}
Worth a try !! ( on a dry run if possible)
Option 2
You might just reverse the stepper by changing the wiring . Its all down to perspective ! WHen you press down your platform should move "down the model" ie the print head (print effect / work point) gets closer to the base layer Try to think of it from the print head & model perspective rather than the physical direction of the platform
Example in a standard Prusa i3 Y axis The print head wants to go away from us to effect a + Y movement but the bed actually moves towards us!
PS What patched Marlin are you using ? Can you share it or post a link to it ...Thanks
Cheers
Phil
( im big my name is Phil and i currently live in SIngapore hence bigfilsing ( old gamer tag) :-) )
Great feature Thanks
I have never used a top down printer but i guess you set the start position manually according to the level of resin . So from that i guess you will need to "tell" the printer that that = Z home ( or zero)
CW just starts normally and relies on you having manually homed the printer ( or in your case manually set the start point
So if that logic is true then i guess in your start of print job G code, you need to set the Z to zero with the gcode command G92 Z0
You might also need to make sure the printer is using relative coordinates
Hope this helps
I think you need to do more research on servos and servo control in order to understand what it is you are doing. I would certainly recommend detaching the servo from your printer while you experiment.
Having never needed to use a servo my best guess would be the same port as is used in FDM printing for a bed level sensor From what i can see it goes on AUx 1
http://www.thetechwizard.us/download_fi … Servos.png
One thing you have to remember is that it is drawing power from the arduino so be careful not to overload it !!!
BEWARE !!! this is for a different printer but give you some ideas and things to check
https://drive.google.com/file/d/0B8xCOd … ZvVnM/view
must be in the setting on NanoDLP then or you need to set up a printer profile . Im not at my workshop now so dont have a working machine in front of me.
the code should be taken care of by NanoDLP Assuming you have set it up correctly
You should be able to manually operate the Z axis directly from the program as a way of testing it
yes . You need to open the Marlin firmware Look for config.h file and its in there
Look for
const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
and where you see the word "true" set it to "false" or vice versa
https://www.arduino.cc/en/Main/OldSoftw … ases#1.0.x Download and try with Arduino 1.0.5-r2
is it normal to see error messages when uploading marlin? even if it says at the end that the upload is done?
No it is not normal . at least not in my experience.
Strange ! Are you using a Pi3 with onboard wifi or a Pi2 and a USB wifi dongle Im just thinking maybe there's a port conflict .Sorry but im not very good with Linux and port debugging Hopefully somebody else will step in and help. You should be able to SSH into the Raspi and check the ports.
here was my issue >>https://www.nanodlp.com/forum/viewtopic.php?id=295
I think may be different but worth checking
I'm not 100% sure but i seem to remember having a similar issue and it being the serial port Unfortunately i don't have a Raspi Nano set up with me so i cant test it
I'm just looking for my request for help from a few months ago
Ok good
the nest thing to check is to see if you have the correct serial port set up in Nano dlp so the Raspi can communicate . On the main Nano page can you see if the ramps is connected ? Are you getting any error reports ?
Not enough information!!
Has it ever worked /moved ?
What firmware have you loaded onto the ramps?
With any ramps board i would recommend testing it independently first. There is some test firmware available here >>http://reprap.org/wiki/File:RAMPS14_test.zip
Once loaded the firmware just moves all axis forwards & backwards without any user input which allows you to check the ramps is working and allows you to set up the motor current.
Beware thou because it works regardless of axis position or endstops so make sure the axis is at it mid point and can move backwards and forwards without crashing into something.
Hi. The pot controls the stepper motor current regardless of which microstep jumpers are installed. 0.8 VDC sounds about right There is a very slight chance you have a step stick with a different shunt resistor ( used to allow us to read an amperage as a voltage) that has a different conversion factor. Apparently some of the Polulu clone manufacturers decided to change that years ago for some unknown reason.
My best guess is that because you dont have an end stop installed, the firmware sees the endstop as "triggered" and so wont move The other thing is that most firmware needs each axis ( in our case only Z) to be homed before any other input is accepted
As such it will only allow movement in the home direction until it triggers the end stop. It kind of makes sense because at power up the firmware has no idea what position the axis is in so needs to see the home endstop triggered before anything else.
Endstops usually use the NC ( normally closed) contacts for safety's sake. so with no endstop fitted the circuit is "open" so it considers the endstop as triggered. Be careful you identify the terminals correctly and dont short out the 5VDC on the ramps
I don't have access to my printer right now so cant help with the settings sorry
If i were you i would load the test firmware and getting the stepper motor working and the current set up first. Remember to put the axis in its mid way position because the test firmware moves the motor backwards and forwards regardless of the axis starting point
i usually approach it in this order
get the motor moving
set the current
set the direction
set the homing direction
set the end stop logic
Good luck
Loads noob and get networking working properly then consider Nano DLP
