Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some requests #239

Closed
ghost opened this issue Jan 1, 2018 · 4 comments
Closed

Some requests #239

ghost opened this issue Jan 1, 2018 · 4 comments

Comments

@ghost
Copy link

ghost commented Jan 1, 2018

Just before opening the COM port, would it be possible to add the line of code "com.DtrEnable = true;" so Smoothieboards know LaserGRBL wants the connection message?

Also, not sure if it's my port of GRBL - but when I'm in Alarm state, I can't connect (seems to time out) but it could be because of the alarm message being sent on connect.

My laser isn't finished yet, so I can't tell if this is a good idea or not at the moment, but running your generated picture gcode on the bare electronics on my desk has long pauses on every "S0" command at the end of each raster line. I can make them go away if I change it to "G1 X0 S0", relative mode means X doesn't actually move, but which tells GRBL to not leave G1/2/3 mode and pause so much.

Thanks.

@arkypita
Copy link
Owner

  • Dtr managment added to dev roadmap
  • question about alarm state not clear, explain better
  • grbl has laser mode since v1.1 with laser mode enabled you have different managment of G1/2/3 with smoother movement and no pause

@ghost
Copy link
Author

ghost commented Jan 31, 2018

Never mind the alarm state, I can't reproduce it anymore (at one stage I didn't have the emulated eeprom working on my 32 bit port and was seeing "error: 7" before the connection message - but even reproducing that isn't preventing a connection). Not sure what happened there now.

Regarding laser mode, you're right - that generally works very well now.. However, if you set "Step idle delay" to 254 (the maximum) then just using S0 (and not something like G1 X0 S0) shows a quarter second delay at the end of each raster line when it leaves G1/2/3 mode and disables the steppers.

(Being on a 32 bit platform and having lots of flash space free, I've altered GRBL so the idle delay isn't a simple delay call in stepper.c when the stepper disable occurs, but is rather a timed idle loop check instead making it more asynchronous which also fixes the issue for me. I.E. the steppers don't get disabled if a new gcode command comes in within 254ms. But that's beside the point.)

Good work here by the way, this program makes using my laser much easier.

@arkypita
Copy link
Owner

Version 2.8.43 add DTR managment
https://github.com/arkypita/LaserGRBL/releases/tag/v2.8.43

@ghost
Copy link
Author

ghost commented Apr 11, 2018

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant