You are not logged in.
We have some new error recovery function unfortunately it still beta.
Could you share /var/log/syslog ?
Adam,
Is it normal response from Trinamic drivers?
You are not on the latest build? Which build you are using?
Please, share /var/log/syslog file dump too.
Once such error has been reported and culprit was raspbian graphic stack which hijacked gpu access. Do you use full version of raspbian or lite version?
We have a similar request from one of printer manufacturer which we are working on. It is already possible to hack things together but any change on our side could break things on the other side.
I am middle of pretty sizable new features after that I will check to see if we could stabilize things and release API.
Unfortunately it would not be possible to support it directly. You can try python script but I am not sure if you could achieve good speed.
It could be helpful https://www.raspberrypi.org/forums/view … 49&t=55580
I have imported both SLC and SVG files and processed perfectly.
It is the first time I am seeing "unsupported value: NaN" error, do you receive it just after reboot too?
Could you try beta version? I have updated that to make sure it print out more info on failure.
(wget http://www.nanodlp.com/nanodlp.beta.tar.gz -O - | tar -C /home/pi -xz);cd /home/pi/printer;sudo ./setup.shAlso copy of following folder will be useful, you can copy it using winscp or a similar program
/home/pi/printer/db
Hi,
I am not familiar with these driver boards, but I have take a quick look at spec. If you are using that to drive stepper motors only 2 pin per motor required one for step another for direction which is the exactly same as we currently use, apparently additional enable pins are for PWM (servo) not steppers.
So I think it could be used by nanoDLP too. Be careful with logic voltage of rpi board.
Hi,
Could you post part of your log file?
If the preview always black, it could indicate problem with your stl/slc file.
If you could share SLC file, it also could be useful.
You need to run it from windows command prompt.
What kind of error do you receive?
Statement is correct about both motor and actuator but not speed. Speed gets ignored completely.
If you set settings for actuator/motor/driver correctly you can use manual movement buttons, if not you can add custom buttons. Custom buttons are mostly used to add custom functions such as drain resin and etc.
We have plan to move positioning from ramp to rpi soon. But it will be backward compatible with the way it works now.
Fixed, thanks
Woale,
nanoDLP designed for direct control, ramp support added afterwards, so it still lag behind.
All of these settings you mentioned above mostly required for direct control and manual movement. You need to put speed related settings directly into gcode boxes.
Actuator settings would not have effect during print as currently ramp board would do all of positions. Z-Axis height also related to positioning.
About manual movement, probably one of these settings is wrong: Microstep, Motor Angle, Leadscrew pitch
Leadscrew pitch is distance travelled on each turn of leadscrew.
Modifying muve3d version probably will be easier. Just do not forget to remove [[WaitForDoneMessage]] from gcode boxes as it require patched grbl/marlin.
More information on patched firmware
http://www.nanodlp.com/forum/viewtopic.php?id=29
https://github.com/kitprinter3d/grbl/tr … l-solidray
https://github.com/mUVe3D/Marlin-mUVe1DLP-Running
Build #1052
Feature: New SD image
Feature: Force Stop
Feature: Improved setup script
From nanodlp itself, setup page, tools tab, you can terminate program by pressing terminate button.
From SSH, execute following command "sudo killall printer" will terminate nanodlp.
You have three seconds at the end of boot procedure to prevent nanodlp being execute by pressing any key on your keyboard.
To remove nanodlp from boot completely, comment following line on /etc/rc.local file by putting # at the start of the line.
/bin/bash /home/pi/printer/config/run.sh
to
#/bin/bash /home/pi/printer/config/run.sh
Thank you for the info.
I will add force stop.
It intentionally blocks restart and shutdown like commands during prints to prevent possible mistakes.
When you put [[WaitForDoneMessage]] message into gcode box, nanoDLP waits until receive Z_move_comp message from ramp board.
Quite interestingly your ramp only sends 'ok' messages back, are you sure you are using patched marlin firmware?
If you are using patched version, is there any similarity for profiles which has this issue?
Stop only works when ramp returns back the control.
Maybe we need force stop somewhere buried inside setup page.
Option 1 should work exactly like option 2 in terms of when to close or open.
Do you think option 1 issue had something to do with nanodlp itself?
Hi,
Fixed, thank you.
Hi,
Currently it works with this order
send gcode start of print / Movement Start => Projector On => Wait for Projector warmup => Start the first layer => Gcode start of layer => Shutter open => Layer display => etc
Apparently muve3d open shutter only once before print. So gcode open shutter code included in start gcodes which runs before projector warmup.
There are quite lots of way to change the behaviour,
1. Move shutter open gcode from "gcode start of print" box to "shutter gcode" box which recently has been added.
2. Wire shutter directly to RPi.
3. Move shutter open gcode to "before layer print gcode" box with conditional which execute it only on the first layer.
Build #1050
Feature: Hardware resource monitor
Feature: Custom buttons support condition
Bugfix: Report problems on graphic stack instead of panicing
Whenever nanodlp reads [[WaitForDoneMessage]] command, it waits for "Z_move_comp" response from 3rd party board. muve3d's marlin version currently patched to do that, grbl is also patched but as I know they have not published it yet.
Problem with ? command is nanodlp should flood grbl to know when movement is completed and detection would not be instant. But using patched version movements completion is almost instantly gets detected.
We are working on couple of commands which will delegate whole positioning from marlin/grbl to nanodlp it will improve things a lot. And [[WaitForDoneMessage]] will be required to make new commands work.
Build #1040
Feature: Calibration plate generator shear option
Feature: USB storage support for plate upload
Feature: Projector warmup support
Feature: Display more details for calibration plate
Bugfix: More details on plate page
Bugfix: Shutdown cancel does not work
Bugfix: Issue with new raspbian
neurofun,
Thank you for the report.
Currently on all of the pages except index page, messages are static and does not get updated automatically.
It requires lots of ajax request or websocket implementation to update those messages. Which is not implemented, yet.
Which build do you use?
Actually it reported before and I hope we have fixed this issue. It happens whenever communication issue raise. If you are not on latest version please upgrade.
Rastati,
You are right about MAX232, it is optional and personally I prefer separate usb serial adaptor.
No, it is possible to use any general purpose gpio to send PWM
Shahin wrote:I will post a new topic for calibration feature shortly. To get feedbacks.
Cool, great. Let me know if and what i can test for you.
http://www.nanodlp.com/forum/viewtopic.php?id=24
You can test beta version.