Any interest in a grbl driver? #21
Comments
|
Hi. I know about smoothieboard. They even proposed to me to implement a VisiCut driver as part of a contest (http://arthurwolf.github.io/SmoothieContest/), which has not started yet. If my project gets chosen and I implement the driver, I get a free smoothieboard ;). Every new diver to LibLaserCut is welcome, because it makes VisiCut more universal. Please fork LibLaserCut on Github and create a pull-request based on the "develop" branch. In order to get your name into the commit-log, please make sure you history is clean with "git rebase -i" (merge commits, which belong together, add meaningful commit-logs etc.) before you push your branch to Github. We can then review your commits in public and maybe improve them (add Ethernet support?) before I merge it into the next VisiCut release. Interesting point about the serial stuff. I never had the opportunity to test any of the serial enabled drivers, because I did never have access to a Lasersaur. Does the serial library work on all OSes? It would be nice to finally have someone testing that stuff. |
|
Well, let's see if we can't get you awarded a Smoothieboard! (I already have several) I'll try and get things into the fork sometime over the next week or so. Based on the java serial port API sample apps I had found for purejavacomm.jar, it's going to be different for each OS. Which follows along with what one might expect for the OS: Linux using a "tty" (ttyUSBx, ttyACMx), Windows the standard "COMx", Mac "tty.usbmodem". It was just the '/dev/' portion that was causing a failed string match on a Linux box in finding the port. I'm happy to test what I can as my free time allows. |
|
Any update on this? I'd love to try out smoothie + visicut on my laser cutter. |
|
I have a cleaned up version of the driver in my LibLaserCut fork but I've only done basic serial port tests. Unfortunately, I started an "upgrade" of my laser cutter and it probably won't get finished until after FRC/FTC season. |
|
Hi, I got a mail, that I won a smoothieboard and it will be shipped on monday, so maybe I can start developing a smoothie driver in the next days. Is your code public, so I can start off from there? |
|
It should be public: https://github.com/dmmlonestar/LibLaserCut . From testing so far, I would recommend changing the default pre/post g-code commands to include disabling the laser. I had one instance where the serial library crashed during a cut. On the next startup, the left over serial data turned on the laser and then the new startup homed. Might also make sense to pull the generateXXX() functions into a sub-class to share across drivers - I suspect there might a need for one-off grbl driver implementations. |
|
Hi, |
|
Do you have a smoothieboard-controlled laser-cutter? I have my smoothieboard connected to some steppers, but in order to test my driver, a real device would be nice. |
|
I was going to try switching a LPCxpresso running smoothie into my LAOS On 12 July 2015 at 17:29, Thomas Oster notifications@github.com wrote:
|
|
As mentioned in my initial post, I do have K40-style laser cutter hooked up to a Smoothieboard. However, I don't have an Ethernet drop in the workshop currently so its interfaced with the serial port using the grbl driver in my branch. |
|
My Smoothieboard driver can use both, ethernet and serial, so it sould work. I'd apprechiate it if you could test it. I had a brief look at your driver, it's pretty much the same, I think. I included a test to check if it is really a smoothieboard (because it sends "Smoothie" as soon as you connect), which allows to try every serial port available. It seems as if you send a power value between 0 and 255? In the smoothie-docs, there it sais the value already is in percent... I am not sure. |
|
The setPower() is a hold-over from the Lasersaur driver I believe. I have a manual control for laser power so it's a no-op for me. But it looks like from the docs and the firmware's use of strtof(), it should be 0.0 - 1.0 to set power (0 - 100%). I don't see any flow control on the serial port in your driver - when I set up the driver in my branch it appeared to be necessary to check CTS and send the job's datastream in chunks (hardware's UART FIFO is 16 bytes) to avoid losing data and breaking the stream. Also, I more recently discovered it was also necessary to drain the serial ports input stream as eventually the Smoothieboard's "OK" responses will fill the hardware FIFO and cause an error condition on the smoothieboard itself (based on the LEDs). This showed up a larger complex cut. I can probably get some testing of your driver done by this next weekend. |
|
You're right about the float control. I did not test it, I thought the USB-UART chip would take care of it. Also I will add reading of the input (and maybe checking for error reports). The "convertRasterToVector" method is not finished yet, because I see a problem. When converting a line of the raster to a vector line, I have two options for the "blank" parts:
If I think of your cutter, which has a manual power control, I guess G1 command will switch the laser on, even if power is set to 0? Also I did not test, if the G0 command accepts the speed parameter. Does the interpreter hold two different speed values for G0 and G1? |
|
if this is standard G-code, G0 means "move as fast as possible to the specified point". The speed is undefined. G1 means "move with designated speed (as far as physically possible, e.g. acceleration limits) in a straight line". |
|
Ok, so the question is, does the smoothieboard respect G1 with power 0 even if the power is manually controlled? @dmmlonestar, could you try this? I think using G1 commands with the same speed while engraving will make the whole process smoother instead of alternating G1 and G0 commands. |
|
@t-oster is there any plan for a http-upload workflow for the smoothie visicut support? I'd like to keep the workflow largely the same for my users (Laser is at a Hackerspace) if possible, with visicut uploading the full file first, then selecting and running it from the LCD. |
|
Hey. For Smoothie's laser behavior, the module is very straightforward to read : https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/tools/laser/Laser.cpp In short : |
|
This means on a setting where only laser on off is used and the pwm is not connected but power is set externally, a g1 will turn the laser on even with power set to 0. -------- Ursprüngliche Nachricht -------- Hey. For Smoothie's laser behavior, the module is very straightforward to read : https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/tools/laser/Laser.cpp In short : — |
|
On Mon, Jul 13, 2015 at 6:45 PM, Thomas Oster notifications@github.com
There is -only- the PWM pin in the Smoothie module, so that setup pretty
-If- we added a on-off pin ( which should be fairly easy ), adding a
Courage et bonne humeur. |
|
As far as I understood @dmmlonestar he has "a manual control for laser power"... So the question is, how did he wire things? If there is no laser-enable pin, I think I go with alternating G1 S0 and G1 S commands in order to simulate raster lines. Next question is the flow control @arthurwolf , what flow control is supported on the virtual serial port? @dmmlonestar suggests RTS/CTS, but on my tests yesterday, CTS was always set, so I don't know if the smoothieboard really clears it if it's buffer is full. |
|
@t-oster : I wouldn't worry about any special handling to support my manual power control. I can bypass it for testing your driver and I don't expect many setups will have it. |
|
I put all the todos in #23. please continue the discussion there. |
|
@t-oster The "manual on/off control" is done with a "switch" module on the enable pin, but that's only used for safety at the beginning and end of jobs. Appart from that, Smoothie only uses the PWM pin to both set power, and turn on/off while cutting. Using the S parameter to do engraving is the right thing to do ( some python scripts already do this succesfully ). About flow control, it's very simple, it's the same as GRBL, Marlin and the others : Send a line of G-code, followed by a carriage return, then wait for the board to answer "ok". This will let the buffer fill. When the buffer is full, Smoothie waits for room in the buffer before answering "ok". About upload, I advise against both SFTP and Plan9. The best method is just a simple HTTP upload ( look at the web interface ). Should be plenty of libs that do that available. Once the file is on the SD card, nothing happens. You have to tell the board to run it ( by sending "play /sd/file.gcode" to /command/ ), same thing the web interface has an example of how to do that. There are LCD interfaces that allow people to manually launch files too ( see http://smoothieware.org/panel ) |
|
thank you for clearing. I will update the driver this evening. Please use #23 for the discussion. |
|
@arthurwolf Can I find the code of the webinterface or a description of the APIs behind it somewhere? |
|
Well you'll need to access the webif at some point :) If only to test On Tue, Jul 21, 2015 at 7:37 PM, Thomas Oster notifications@github.com
Courage et bonne humeur. |
|
thanks. |
I setup a driver for a Smoothieboard (http://smoothieware.org/smoothieboard) which uses a port of the popular grbl (https://github.com/grbl/grbl). It's basically a tweaked copy of the Lasersaur driver. This is being used on my K40-style import laser engraver/cutter.
Basic tweaks:
I can post a git patch or code snippets/etc if there's interest in getting it added.
On a side note: thanks much for Visicut! It's perfect for my needs.
The text was updated successfully, but these errors were encountered: