Add support for SmoothieWare #204
Comments
|
This sounds super easy to fix. Appart from the boot message, Smoothie should be mostly GRBL-compatible ... |
|
If you un-comment the TinyG line in FirmwareUtils the TinyG plugin might work for Smoothie. The "plugin" model here was never fully developed but most of the architectural changes were finished before I ran out of steam. |
|
Would somebody mind uncommenting that Smoothie (line 41) line and compiling a test version for me please. I don't have NetBeans installed and would be willing to test this and report back |
|
I had some free time at lunch so I thought I'd try this. I'm on a MAC OS X, cloned the project, installed NetBeans, and tried to build (with that line uncommented). Didn't get too far so I thought I'd post this in case you see it and have a quick answer as to what's missing. |
|
FYI, if I download version 1.0.8 it will compile without errors yet TinyG does not successfully issue any commands. Interestingly the visualizer does not work either (did not work for me on the other builds either). If I switch to the edge branch the visualizer and compile work but TinyG does not work either. Looks like more work is needed to support different responses and setups for anything other than GRBL. Maybe a better first test is to edit the code to also look for a Smoothie response and accept that along with the GRBL 0.8/0.9 responses? |
|
@GeorgeIoak You're absolutely right. If you take a look here you can see that Smoothie is not implemented at all. You can also see the pattern setup for switching between different gcode types. Its just like you suggested - a way to support different responses and setups! A lot of the legwork is done I just haven't found the time to setup the electronics for my TinyG and fix the bugs. That work would be done in TinyGCommunicator and TinyGController. For Smoothie two more files would be created to implement these interfaces. |
|
@winder I did make a quick change and bypassed the version check just to confirm that that I could run a file. The good news is that I was able to start a job but the bad news is that the job stopped at the same place 2 times about 1/2 way through (1150/2249 I think). The code that it stopped on (G3) had run successfully earlier in the job so I'm not sure why it stops here. I think Smoothie would be easier than TinyG in that I think Smoothie is a direct port of GRBL and TinyG was branched off of GRBL. I could be wrong on that so don't quote me! Not having the visualizer work is a bit of a bummer and I found some clues to try to get it to work but didn't succeed yet. Once I get a job to run successfully I can help create and test SmoothieCommunicator and SmoothieController. |
|
Hey. Smoothie currently has a G3 problem, so that's probably not a problem with This does sound like you got Smoothie to work with UGS :) Cheers. On Sat, Feb 28, 2015 at 2:32 AM, George Ioakimedes <[email protected]
Courage et bonne humeur. |
|
I'll have to pop over to the Smoothie forums and look into this problem. The code did work once last night using Pronterface but that might have been luck of the draw as I thought I had tested it before and it failed as well. For reference the file I'm experimenting with can be viewed here. Yes, UGS and Smoothie worked together. I'm a hardware design guy mostly so coding doesn't come naturally for me but I'll start taking a look on how we can officially get Smoothie support. I just happen to be testing with a Mac so that might be throwing in some other issues. |
|
@GeorgeIoak Just ran into the same error. Replaced the code snipped (as the Point3d that's being included has no .getX()): public void updateSystemState(SystemStateBean systemStateBean) {
logger.log(Level.INFO, "Getting system state 'updateSystemState'");
double[] mp = new double[3];
this.machineCoord.get(mp);
double[] wp = new double[3];
this.machineCoord.get(wp);
systemStateBean.setFileName(gcodeFile.getAbsolutePath());
systemStateBean.setLatestComment(lastComment);
systemStateBean.setActiveState(activeState);
systemStateBean.setControlState(controlState);
systemStateBean.setDuration(String.valueOf(this.getSendDuration()));
systemStateBean.setEstimatedTimeRemaining(String.valueOf(this.getSendRemainingDuration()));
systemStateBean.setMachineX(Utils.formatter.format(mp[0]));
systemStateBean.setMachineY(Utils.formatter.format(mp[1]));
systemStateBean.setMachineZ(Utils.formatter.format(mp[2]));
systemStateBean.setRemainingRows(String.valueOf(this.getNumRemainingRows()));
systemStateBean.setRowsInFile(String.valueOf(this.getNumRows()));
systemStateBean.setSentRows(String.valueOf(this.getNumSentRows()));
systemStateBean.setWorkX(Utils.formatter.format(wp[0]));
systemStateBean.setWorkY(Utils.formatter.format(wp[1]));
systemStateBean.setWorkZ(Utils.formatter.format(wp[2]));
systemStateBean.setSendButtonText(openCloseButtonText);
systemStateBean.setSendButtonEnabled(openCloseButtonEnabled);
systemStateBean.setPauseResumeButtonText(pauseButtonText);
systemStateBean.setPauseResumeButtonEnabled(this.canPause());
systemStateBean.setCancelButtonText(cancelButtonText);
systemStateBean.setCancelButtonEnabled(this.canCancel());
}Now the code is executed without the error. |
|
I should have a SmoothieBoard in my mailbox today! I am a professional Java developer with 15+ years experience. I do mostly Point-of-Sale automation and control system development with J2SE. I did some enterprise/web stuff for a while but it's been years. I'd be very interested in helping to get this working with Smoothie. Is there any code committed for Smoothie support? If not how can I get what's been implemented so far to help with the cause? Ken |
|
There's an API for adding additional controllers. Currently there is just GRBL and an almost-complete TinyG implementation. You've been working with Java for longer than I have, so I'll be curious to hear you're opinions. Here's a high level overview of how the backend is implemented: Adding full smoothie support shouldn't be bad, it may just be a matter of extending the GRBL controller class and re-implementing a couple functions which are handled differently in smoothie (i.e. version checking). |
|
Thanks for the overview link. I will take a look a little later and get familiarized. I've been using Eclipse for years and have very little NetBeans experience. I need to download NB to get going on this. Ken |
|
I've been trying to get the Smoothie board working. It seems that when it connects, Universal Gcode sender doesn't catch the "Smoothie" hello message. If I force it by setting "isReady" to "true" I can get it to at least allow me to send commands, but each time I get the same error as the timing issue mentioned in #214 Here's a screencast of the weirdness I'm encountering. Another interesting thing is that if I use a serial terminal to connect to the smoothieboard, I get the hello message, but if I connect to Universal Gcode sender, close the connection, then try the serial terminal, I no longer catch the hello message, but I can send commands and receive replies. I tried Smoothie firmware from Jan 15th and June 21, 2015 |
|
Hey. This does sound like some weirdness on windows' serial driver's part, I One thing you can do : instead of just "waiting" for Smoothie to say About the "ok"s, I have no idea what is going on there ... maybe it's Cheers. On Thu, Jun 25, 2015 at 7:50 AM, morrowsend [email protected]
Courage et bonne humeur. |
|
@morrowsend it sounds like you're on the right track. GRBL/Arduino restart themself when connected by USB, it sounds like Smoothie might not have this feature. I've actually been considering whether UGS should rely on it for GRBL as well. Something like Arthur's suggestion is a great first step, there is a function in AbstractController called "openCommAfterEvent" that you can implement to send "version" in your Controller. I recently made a bare bones streaming program to test out some communication changes, you might consider working off of that project while troubleshooting these weird serial issues. Finally... sorry about this, but I pushed a bunch of optimizations to the AbstractController class recently and there might be a couple merge conflicts. You should pull those changes down as they fix some fundamental issues with the AbstractController (it was overly complicated, slow, had concurrency issuese, etc). |
|
All good ideas to help me figure this out. Thanks guys! winder, I forked it last night so I could hack on it to my heart's content (like 12 hours ago from this post) so I assume that the newest changes were implemented at that point. I'll take a look to see if anything is different with the AbstractController class to make sure though. |
|
After playing a bit with it today, I still haven't made progress, but here's what I tried playing around with the openCommAfterEvent method in Abstract Controller:
This is weird because it actually does block the port, however the GUI acts as if it is not opened. I have no ability to send commands and when I try to press the Open button, I get an error popup stating the port is already in use. So with isReady set to true, I did the following:
Throughout all of this, I have a breakpoint set at the rawResponseHandler in the SmoothieController.java (just a clone of Grblcontroller). This breakpoint is NEVER tripped. So my thought are:
I'm at a bit of a loss on what else to try. You can see what I've done so far (not much) here: https://github.com/morrowsend/Universal-G-Code-Sender/tree/master/src/com/willwinder/universalgcodesender |
|
A couple things. It looks like I am manually resetting GRBL after opening the connection, so you are sending the GRBL reset signal to Smoothie, which might be causing the weird behavior. Did you change this part to send version? You'll need to change "sendByteImmediately" to "sendStringToComm": @Override
protected void openCommAfterEvent() throws Exception {
// GRBL_RESET_COMMAND is 0x18
this.comm.sendByteImmediately(GrblUtils.GRBL_RESET_COMMAND);
}Another thing you can try, is in GrblCommunicator.java change "\r\n" to just "\n" The weirdest thing I'm seeing in your update is the "nullok" response. I'm not really sure what thats about. I think the error part is happening because UGS doesn't think its sent a command, but its getting a response anyway, but I'm not sure why it says "null". |
|
Great, I've got an update. I had to make sendStringToComm public in AbstractController public but that fixed the issue of check if it receives the hello message. I was able to successfully manually drive the machine, but I get an error when I try to send a file.
|
|
Ah, sorry I gave you the wrong method. Don't change sendStringToComm to public, use the public version which is "sendCommandImmediately". That should fix the file send error. The multiple OK thing looks like it might be sending an OK for each command in the line. For instance the first line in your screencast was "G21 G91 G0 Y1", that has 3 G commands and received 3 OK's. The second command was "G91 G0 Y-1", 2 G commands and 2 OK's. This is going to be a trickier problem to solve since the current code assumes a single OK for each line sent. You can test it out by sending something like "G21 G21 G21 G21 G21" and seeing if Smoothie responds with 5 OK's I need to figure out that "/n" vs "/r/n" thing. I had the same issue when making the simple gcode sender so I'm not sure how UGS is working in GRBL. Reworking the serial code is next on my list of things to cleanup. |
|
Thanks for the quick reply. I had previously tried sendCommandImmediately, but when I use that, it doesn't even open the port. isReadyToSendCommandsEvent() throws the exception before it will even open the port. The sendStringToComm at least allowed me to open the port. And you are correct about the OK replies, G21 G21 G21 G21 G21 gives me 5 OKs. |
|
Ok, I'll see if I can figure out why thats happening soon. I think you need to use sendCommandImmediately for this, it's probably a bug that sendByteImmediately works (and another bug that neither of them works in this afterCommOpenEvent method). |
|
It's a chicken and egg thing. If I force "isReady" true, then I can use sendCommandImmediately, but if I want to use isReady, then sendStringToComm has to be public. Regardless, if I set isReady true, and use sendCommandImmediately, I still get the same issue when I try to stream the file. Thanks for all the help so far. |
|
Any of the constructs created in GrblController are specific to Grbl and can be removed if they don't make any sense for Smoothie. Thats the intention anyway. In this case it looks like isReady exists because it made sense for Grbl - there are features that get conditionally enabled depending on the Grbl version. It sounds like it doesn't make sense for Smoothie so you can just take it out completely in SmoothieController. I think the "Error: Cannot stream when there are active commands" problem is related to the multiple OK's. In AbstractController there is a single ArrayList with all the commands in it. I use indexes into that array to determine which commands have been sent, which are waiting on responses and which have completed. One of those indexes gets incremented for each OK received which is going to cause issues. I'm surprised that the standalone gcode streaming app worked, since it counts OK messages in the same way. If you remove isReady and remove the "version" query then send a file before sending any other commands I think it will appear to stream the file correctly, but the indexes will be corrupt. |
|
I did what you said, (just keeping isReady true, and removing the "version" command). I can send it a file, but it only executes about 5 lines then stops streaming. This is repeatable with different files. I can get the entire file sent using the simpleJavaStreamer with no problem. |
|
Thats probably the multiple ok's, were you able to figure out if that was because of multiple gcodes per line? You could try running something like stress_test.gcode which happens to only have 1 command per line. |
|
The stress test code gets stuck on the 11th line in UGS. It works in the
|
|
I spent some time this weekend adding TinyG support. The AbstractController interface worked pretty well, I really didn't need to change anything there. The Communicator also worked pretty well, the TinyG / Grbl buffered communication was 95% identical so I re-factored it so they both extend a "BufferedCommunicator", Smoothie may want to extend that as well to implement the "processedCommand" function to deal with those multiple OK messages. We might need to add a "sentCommand" function to implement for smoothie as well to deal with the multiple ok messages. Take a look at TinyGController and TinyGCommunicator, maybe this will make a little more sense with a simpler example. I was hoping to find a bug in the AbstractController that might be causing your problem, but everything seemed to behave as designed. Another possibility is that the status messages are causing an issue, try disabling those (there's a GUI setting). |
|
If it works in pronterface, you need to use pronterface, and get the error On Thu, Aug 25, 2016 at 11:20 AM, tigerpolis [email protected]
Courage et bonne humeur. |
|
The error never happens in pronterface, just with UGC when i start the connection. Yes i have limit/home for x and y min, works in pronterface as well. |
|
Looking back in this thread it looks like there might have been a couple other changes @morrowsend had made. It seems like there might be a little more work to get UGS to interface with Smoothie. One change is to remove the |
|
@winder Control X is the problem here, it does not reset smoothie (that would be reset and is not needed). Control X puts the sysem into Alarm state. Also as Smoothie has many GRBL features now it needs to be put into grbl mode by adding |
|
|
|
@wolfmanjm Thanks for the feedback @tigerpolis if you could try the nightly build, I removed the |
|
I will try it tomorrow! I can download the new build from this link ↓ right? (I'm quite new to github) |
|
Yep, thanks On Thursday, August 25, 2016, tigerpolis [email protected] wrote:
|
|
Not working :/ just getting this now: |
|
@tigerpolis I fixed these two errors. Looking back in this issue the |
|
@winder smoothie ignores \r, so would not send ok twice. |
|
@wolfmanjm I was basing that off of a comment from last year:
|
|
I will see if i can check the new build this weekend, otherwise on Monday! Thanks! |
|
Ok so there is some progress, i can now connect and move the machine, but only 9 steps then it becomes unresponsive in all directions. Also i get some weird message: |
|
@tigerpolis I just made another change to make sure single-step mode is enabled for Smoothie. |
|
Now i can only move one time then when i click again nothing happens, no error, nothing! Have to disconnect then connect again to move one step again! |
|
It seems like there is more to this than I expected. I'm not sure I'll be able to trouble shoot this remotely. |
|
Basic smoothieware support has been added. If you have the chance, give it a try. But be careful, it's brand new and there will be bugs! =P Make sure you are running smoothieware with build date: Jul 3 2019 21:32:06 or later. |
When I try to use Universal GCode Sender with my new Shapeoko running Smoothieware I get this;
**** Connected to COM10 @ 9600 baud ****
Smoothie
[verbose][Error] Error while processing response : Attempting to complete a command that doesn't exist: <(-1)>ok
Then if I try to send gcode I get
"Error while starting file stream: Grbl has not finished booting"
The text was updated successfully, but these errors were encountered: