arduino doesnt respond

[scales11]

Hi.

Thanks for your work on the chrome gcode sender, I love the interface and it seems to be one of the most responsive gcode programs that I have used.

I did however run into a problem and thought I would reach out to you for your opinion. I ran a job on my cnc and it froze towards the end of it. Now, my arduino will connect to the chrome gcode sender, but I am unable to send any commands to it. I can however connect and control the arduino using another gcode sending program.

Have you ever seen the arduino refuse to respond to the chrome gcode sender, but work fine with other ones?

Thanks!

[sir-buckyball]

Thank you for the kind words.

A non-responsive connection is one of the more annoying issues to track down. To get up and running again, I would suggest closing the gcode-sender application and opening it again. Make sure you have the connection port set correctly and that no other programs on your computer are holding a lock on that port (eg., arduino, a screen terminal, another gcode sender application).

I pushed an update 2 days ago which fixed an issue when running against a grbl flashed arduino board. It turned out that grbl would send an additional 'ok' in response to a carriage return. The "fix" was to terminate command with a "\n" instead of "\r\n". If no commands are working for you, this could be at fault.

Do you by any chance have some reproduction steps? What software is running on your Arduino board? What was the input gcode file (and about where did it fail)? What operating system are you using?

[sir-buckyball]

So I just experienced something similar to what you have described. I had mistyped a gcode command such that it was malformed. The response from my grbl board was an error. Importantly, no "ok" was sent in response. The gcode sender application blocked itself assuming the board was not ready for more commands and all further commands were enqueued instead of being sent.

Is the same as the problem you had?

[scales11]

Thanks for replying. I will sit down with my CNC tonight and give you a detailed overview of what I am doing and what I see when I fire up the application. Again, I really like your program and would be happy to contribute with as much feedback as I can. I have taken enough advice and knowledge from others when researching CNCs so I am happy to give back. For starters, here is my setup:

1. Arduino Uno running GRBL 8.0c (although I do NOT think it is the newest release-12/07/13)
2. I have 4 of these stepper drivers: http://www.amazon.com/SainSmart-Router-Single-Stepper-Stepping/dp/B008BGLOTQ/ref=sr_1_4?ie=UTF8&qid=1395666551&sr=8-4&keywords=stepper+driver --I know that the chip has a bad reputation, but they were cheaper and I didn't want to dump money into my project until I knew I could finish it and things would work (I designed and built my cnc) --I can say though that I expected smoother performance from my motors and drivers, I can still hear the "stepping"
3. I have 4 of these motors: https://www.sparkfun.com/products/10847
4. I have a 25V switching power supply with 6A (I think, will confirm later)
5. As far as the wiring goes: --The motors are unipolar but I did not wire up the center taps --The "step-pulse" arduino pin is wired to the "CLK+" on the driver --The "direction" arduino pin is wired to the "CW+" on the driver --The other driver pins (all with the "-") are wired to the arduino ground (NOT the same ground as the 25V PSU) --The "EN+" on the driver is left unconnected --The arduino is powered through my computer usb port with what I think is an insulated USB cable
6. I read that the arduino can sometimes be flaky if the cable runs next to some AC lines, like those going to the PSU. I have tried to keep the cable away from them, but still have trouble.
7. Note: I have closed and re-opened the application several times without a change. I have also rebooted and still was unable to talk to the arduino. In all cases though, I CAN connect to the arduino, just not send commands.

Thanks again,

[alecf]

One problem that I often had on OS X with Prontrface was that the machine went into a sort of semi-sleep mode (Power Nap I think is the name apple gives it) and that would hang the USB connection for some reason - it would literally only happen for me when I stepped away from the computer, but long before the "sleep" timeout. (Fixed eventually on OSX by disabling powernap specifically for Pronterface) Is there any chance that that any of the chromebook models have some similar sleep mode that is hanging the serial interface? (I'm assuming the issue is on ChromeOS, not Chrome.. )

[scales11]

Alecf,

Sorry I forgot to include the fact that I am running a server (bare version) of Ubuntu off of a netbook. I have installed google chrome and am running the program from there. I have not setup any sort of power management, so I don't think that is the problem. Thanks for the thought thought!

One other thing: I can use other gcode sending programs with the arduino just fine. For some reason, ONLY chrome-gcode-sender is having this problem.

[sir-buckyball]

alecf:

Is there any chance that that any of the chromebook models have some similar sleep mode that is hanging the serial interface?

When connected to a machine the application requests that the system not sleep using the chrome.power api (http://developer.chrome.com/apps/power)

scales11: Thank you for describing your machine setup. I'm running the same grbl version which should make testing on my side much easier.

One issue I am aware of is that the chrome.serial api (used for communications) is not stable (eg., they are still finishing it). What this means is that support across platforms is iffy. For example, it works on my chromebook 11, 2010 imac, and 2010 macbook, but it does not work on my 2006 mac mini (important connection parameters are ignored resulting a connection which has an incorrect checksum bit set).

Ubuntu (debian) can be particularly difficult when it comes to serial connections as by default you need to be root to set the permissions effectively (eg., Chrome cannot always do it for you). The chrome-gcode-sender app should warn you if it detects that the connection is not what is expected, but it is possible I missed a check.

In terms of debugging, it would be useful if you had the javascript console open when trying to connect and send a command. Some errors may only appear there. You can get to it by navigating to "chrome://extensions" and clicking on the main.html page for the application.

It may also be worth trying to restart your computer. Yes I know that sounds silly; but serial connection resources don't always deallocate as expected (they are maintained by the system and the Chrome application). Rebooting is about the only way to be sure you are on a clean slate.

PS. If you did encounter the issue I mentioned in update #3, I pushed a workaround in the console log menu this morning.

[scales11]

Thanks for the suggestions. I have restarted my computer several times in the past, and it has not really helped. I also know that I have already added my user to the proper group so that I have access to the serial port. I was able to play with it some more last night, however my results were mixed and may make things more confusing. Here is an outline of my steps: --I gave my netbook a fresh boot and launched chrome --I opened chrome-gcode-sender --I connected to the arduino running grbl --I was able to send movement commands (such as G1 X10), to which the arduino responded and the cnc moved appropriately --I pressed the X-Home button, again everything responded properly --I went to the "load file" tab to find that the application had frozen --I killed the application and re-launched it --this time it froze just after I clicked the connect button.

Is there a chance the arduino gets stuck in some state?

Given these new results, I am thinking about wiping/re-flashing my arduino. I also need a solid and stable gcode sender as a reference to make sure it isnt my arduino that is acting up. Any thoughts on this? Perhaps recommendations?

[sir-buckyball]

Can you describe the frozen behavior? Was it before or after you loaded a file? If it was after, what was the contents of the loaded file? Was there anything interesting in the javascript console when this happened?

What version of chrome are you running? "chrome://version"

If you have a spare arduino laying around, there is a sketch in the testing directory of this project. I've been using that code as a bootstrap for simulating certain conditions using a real serial connection, but a fake "machine".

If you are inclined towards programming, it's fairly simple to clone the repository and load up the extension locally so you can test changes to see what works and what doesn't. I apologize for the state of the code, it could have been cleaner.

I'd be weary of the home buttons. They work fine for 3d printers, but the nature of CNC milling machines means you rarely have a consistent "home" point. Mine doesn't have end stops. I believe the default settings for grbl are to mostly ignore home commands or go to where the machine was started. I've been considering removing them once there is a way to easily add custom buttons (so those who have end stops can re-add their own custom buttons)

I also need a solid and stable gcode sender as a reference to make sure it isnt my arduino that is acting up. Any thoughts on this? Perhaps recommendations?

Here is the recommendations page from the machine I have. I used printrun since I had it installed on a machine in the shop already (admittedly it's meant for 3d printers, but it can send gcode).

http://www.shapeoko.com/wiki/index.php/Communication_/_Control

[sir-buckyball]

scales11: One more question for you. When you experience the issue with the gcode sender, what baud rate are you using? If it doesn't match your grbl controller, then communication won't work well.

[scales11]

sir-buckyball:

Sorry for the late reply, things have been busy. I experience other problems with gcode-sender, mostly hangups and an occasional disconnect. But I have run several gcode files through the "simple-stream.py" included with grbl and have NOT had any issues.

I am finding ways to reproduce my problems with chrome-gcode-sender. Now it is to the point where I can connect to the cnc, manually control it fine with the movement keys. However, the second I click another tab, it freezes. I am wondering if it is something with my chrome. I will look up how to activate the java console and try to get more output when things hang up. Stay tuned for more details, including the version of chrome that I am running.

[scales11]

OK. Will be working with the CNC lots today here is where I am at:

1. I am using Chrome version 33.0.1750.152
2. Chrome Gcode Sender opens in a different window for me, how do I enable a console so I can debug it?
3. My Baudrate is the recommended 9600
4. I am using Java version 1.6.0_30 on my Ubuntu 12.04
5. Problem is not my Arduino, my other python-gcode-sending scripts work fine.
6. Here is how I can reproduce the freezing: --I open Chrome Gcode Sender --I click connect, no problem --Connects fine --I manually more the tool around with the arrows on the keyboard or screen --Click "settings"-->no problem --Click "About"-->no problem --Click "Load File"-->FREEZES --If I click "Control Panel" or about after it freezes, it may respond and take me there after a minute or so, but I cannot get to the "Load File" tab.

[sir-buckyball]

1. I am using Chrome version 33.0.1750.152

The current stable release of chrome is 34, so you should probably update your system

1. Chrome Gcode Sender opens in a different window for me, how do I enable a console so I can debug it?

You can in a separate window navigate to chrome://extensions/ . Once there, make sure the 'Developer mode' checkbox is checked, then you should be able to click on the 'main.html' inspect views link. That should bring up the javascript console for the application.

1. My Baudrate is the recommended 9600
2. I am using Java version 1.6.0_30 on my Ubuntu 12.04

The chrome-gcode-sender application does not use java, so the version of java you have installed shouldn't matter.

I should point out here that Ubuntu 12.04 is actually 4 major releases behind. It is however the most current Long-Term-Support release.

1. Problem is not my Arduino, my other python-gcode-sending scripts work fine.
2. Here is how I can reproduce the freezing: --I open Chrome Gcode Sender --I click connect, no problem --Connects fine --I manually more the tool around with the arrows on the keyboard or screen --Click "settings"-->no problem --Click "About"-->no problem --Click "Load File"-->FREEZES --If I click "Control Panel" or about after it freezes, it may respond and take me there after a minute or so, but I cannot get to the "Load File" tab.

This sounds like the application hung for a period of time, but did not actually freeze. Hopefully there is some interesting information in the javascript console when this occurs.

I recently filed a bug where I noticed that the load-file tab was taking a long time to display (~2 seconds). I've traced this down to significant memory garbage collection events, but have not yet determined a fix. https://github.com/sir-buckyball/chrome-gcode-sender/issues/26

[scales11]

I tried to view the console, for the extension. I followed your: --You can in a separate window navigate to chrome://extensions/ . --Once there, make sure the 'Developer mode' checkbox is checked, --then you should be able to click on the 'main.html' inspect views link. --That should bring up the javascript console for the application.

But was not sure what you meant by "main.html" I was however able to click on the "inspec views:background page" for the extension. That brought up a console, but there doesn't seem to be any javascript or html..here is a screenshot: http://i.imgur.com/V99HLlV.png

I agree that the extension "hangs" when I click the "Load file" tab. But if I wait, till it responds, I can choose a file to send. I then noticed that if I try and send the file to the machine, nothing happens and there is not any response.

[sir-buckyball]

If there were any errors, they would show up in the javascript console for the main.html page. I've attached a screenshot trying to show how to get to that console. The background page is an artifact of chrome; there would be no errors on that console.

[scales11]

OK thanks for the tip. I will try updating my version of chrome next.

[scales11]

Well I just installed a fresh version of archlinux and am using the latest version of chromium. I have not tried to cut anything with it yet, but I do still see the same lag (>5-8 seconds) when trying to access the "load file" tab.

[sir-buckyball]

Issue #26 (https://github.com/sir-buckyball/chrome-gcode-sender/issues/26) is for the lag in the load-file tab. I'm experiencing it too. I'm just going to rewrite that code. In another project I've learned a trick with paperjs which should simplify the code.

Aside from the lag, is it working for you now (eg., actually sending a file).

[sir-buckyball]

scales11: I've just pushed version 2014.5.6.0 which should be faster at opening the 'load file' pane. Please let me know if that version works out better for you.

[scales11]

Thank you for your help and hard work. I will try and test tonight. Fingers crossed, looking forward to using your program more :)

On Wed, May 7, 2014 at 1:15 AM, Buck Clay notifications@github.com wrote:

scales11: I've just pushed version 2014.5.6.0 which should be faster at opening the 'load file' pane. Please let me know if that version works out better for you.

Reply to this email directly or view it on GitHubhttps://github.com/sir-buckyball/chrome-gcode-sender/issues/24#issuecomment-42390275 .

[scales11]

I did notice a much faster load time for the "Load file tab". Unfortunately, it does not send the file when I try. Nothing froze, it just sat there though doing nothing. Here is what I saw in the console:

######## estimated execution time: 0 second main.js:213 renderGcode: gcode processing: 0.064ms main.js:440 renderGcode: 141.148ms main.js:463 connecting to '/dev/ttyACM0' with options: {"bitrate":9600,"ctsFlowControl":false,"dataBits":"eight","parityBit":"no","stopBits":"one"} main.js:773 serial connection obtained: {"bitrate":9600,"bufferSize":4096,"connectionId":1,"ctsFlowControl":false,"dataBits":"eight","name":"","parityBit":"no","paused":false,"persistent":false,"receiveTimeout":0,"sendTimeout":0,"stopBits":"one"} main.js:783 processing file: text-test.nc main.js:100 readFile: 26.959ms main.js:105 extractCommandSequence: 42.952ms main.js:170 estimated execution time: 4 minutes, 23 seconds main.js:213 renderGcode: gcode processing: 147.507ms main.js:440 unknown gcode command: G64 main.js:456 unimplemented gcode command: M6 main.js:456 renderGcode: 617.282ms main.js:463 enqueing file command sequence. main.js:951 ########

On Wed, May 7, 2014 at 10:25 AM, Nick nmf138@gmail.com wrote:

Thank you for your help and hard work. I will try and test tonight. Fingers crossed, looking forward to using your program more :)

On Wed, May 7, 2014 at 1:15 AM, Buck Clay notifications@github.comwrote:

scales11: I've just pushed version 2014.5.6.0 which should be faster at opening the 'load file' pane. Please let me know if that version works out better for you.

Reply to this email directly or view it on GitHubhttps://github.com/sir-buckyball/chrome-gcode-sender/issues/24#issuecomment-42390275 .

[sir-buckyball]

Thank you for attaching the console output. Assuming this is the entirety of the output, it looks like it successfully rendered your file and enqueued it to be sent to your machine. That narrows down where the problem could be. I can at least add more logging there.

Would you mind attaching your file (text-test.nc), or pasting the contents into this bug. I'm curious if there is a header at the top of the file.

[sir-buckyball]

scales11: One more thing I'd like you to try. When you press 'send to machine' and nothing happens, I'm assuming that the console is showing some number of enqueued commands. To the right of the enqueued commands number is a menu pulldown. Can you try selecting "stop waiting for 'ok'" option from that menu?

In another bug you described that you pressed disconnect while zeroing. If you press disconnect while there is a command outstanding, it can result in the application not receiving an acknowledgement for a command sent. It would refuse to send anymore commands until it got that acknowledgement since this is the machine's way of rate limiting commands.

[sir-buckyball]

FYI: version 2014.5.7.0 may help if it's the issue alluded to in my previous comment.

[scales11]

Here is the gcode for the "text-test.nc" http://pastebin.com/x9W6eYkE

Your other comments describe good things to check. I will give them a look today.

On Thu, May 8, 2014 at 2:02 AM, Buck Clay notifications@github.com wrote:

FYI: version 2014.5.7.0 may help if it's the issue alluded to in my previous comment.

Reply to this email directly or view it on GitHubhttps://github.com/sir-buckyball/chrome-gcode-sender/issues/24#issuecomment-42516059 .

[scales11]

Great news, it looks like clicking the "stop waiting for OK" did the trick. I did have to do it several times, but I think everything worked ok after. I did not really watch the actual movement, since I just ran the gcode with the motors turned off.

Do you think this is a problem with Cambam? I would be a little suprised since the simple_stream.py script runs the same gcode just fine....

On Thu, May 8, 2014 at 6:23 AM, Nick nmf138@gmail.com wrote:

Here is the gcode for the "text-test.nc" http://pastebin.com/x9W6eYkE

Your other comments describe good things to check. I will give them a look today.

On Thu, May 8, 2014 at 2:02 AM, Buck Clay notifications@github.comwrote:

FYI: version 2014.5.7.0 may help if it's the issue alluded to in my previous comment.

Reply to this email directly or view it on GitHubhttps://github.com/sir-buckyball/chrome-gcode-sender/issues/24#issuecomment-42516059 .

[sir-buckyball]

Cambam appears to just be CAM software, so there's really no possibility of it causing issues with your machine directly (it only generates a set of instructions [gcode]).

Reading through the source of simple_stream.py (https://github.com/grbl/grbl/blob/master/script/simple_stream.py#L34), it appears that it only waits for a newline character, and does not care if it is an 'ok' or an 'error'. The chrome-gcode-sender application will only continue on an 'ok', anything else will cause it to pause. If you look in the console readout, the response is printed so it should be obvious if the machine didn't like the code.

Are you still having any issues which need this bug to be kept open? Your response sounds like it is resolved.

[scales11]

If I can figure out how to make the code run without the program getting stuck waiting for the "OK", that would be great...I suppose that is different from the initial "bug" that I filed.

Sorry, I do not mean to come off as demanding. It is your program and I appreciate all the hard work you have put into it. I am sure you could mark this bug as solved. Would you mind sharing another tip or advice on how I could get around this "OK" delay?

On Sat, May 10, 2014 at 11:07 AM, Buck Clay notifications@github.comwrote:

Cambam appears to just be CAM software, so there's really no possibility of it causing issues with your machine directly (it only generates a set of instructions [gcode]).

Reading through the source of simple_stream.py ( https://github.com/grbl/grbl/blob/master/script/simple_stream.py#L34), it appears that it only waits for a newline character, and does not care if it is an 'ok' or an 'error'. The chrome-gcode-sender application will only continue on an 'ok', anything else will cause it to pause. If you look in the console readout, the response is printed so it should be obvious if the machine didn't like the code.

Are you still having any issues which need this bug to be kept open? Your response sounds like it is resolved.

Reply to this email directly or view it on GitHubhttps://github.com/sir-buckyball/chrome-gcode-sender/issues/24#issuecomment-42744292 .

[sir-buckyball]

sorry for the delay; vacation.

I'm afraid I'm all out of ideas on why you have to keep using that workaround. That should only happen if your machine were not properly acknowledging the commands being sent; yet the grbl code you said you were using is known to work...

Is it possible that the communications between your arduino and computer are compromised, or that the tx port on your arduino has been shorted such that it cannot properly send data back to the computer?

[scales11]

I appreciate the reply, hope your vacation was good :)

I will look into it, but I suspect that the physical connection is not a problem. I am leaning towards the idea that there is something goofy with the header of the cambam code. This error seems to always be a the very beginning of the gcode and sometimes when I link multiple gcodes together. It just seems to "consistent" to be a connection problem.

I will review the gcode and grbl and get back to you. I think that you can close this error in the mean time, since everything else seems to be working.

Thanks!

On Fri, Jun 6, 2014 at 12:32 AM, Buck Clay notifications@github.com wrote:

sorry for the delay; vacation.

I'm afraid I'm all out of ideas on why you have to keep using that workaround. That should only happen if your machine were not properly acknowledging the commands being sent; yet the grbl code you said you were using is known to work...

Is it possible that the communications between your arduino and computer are compromised, or that the tx port on your arduino has been shorted such that it cannot properly send data back to the computer?

Reply to this email directly or view it on GitHub https://github.com/sir-buckyball/chrome-gcode-sender/issues/24#issuecomment-45302032 .