Forum Replies Created
-
AuthorPosts
-
Rural
MemberSo Chilipeppr now supports multiple hardware options (tinyg, grbl, etc.) when communicating with the SPJS. We had it set to “default”. Apparently, the behavior of that option has changed, or maybe we had used “tinyg” in the past and somehow got set it to “default” recently. It turns out that won’t work.
The best part is that Chilipeppr even has an attention getting blurb warning users of TinyG hardware to use the “tinyg” setting for the SPJS. I managed to avoid seeing while my panic built for about an hour. Did a head-slap when I actually read the warning. My face is red.
In any case, when we changed the option to “tinyg” everything began to work as expected. The cutting has resumed!
John also caught this right away on the Chilipeppr Google group. That fact really impressed the machine’s owner, and myself, given my panicked description of the symptoms. One more believer in open source.
MemberThink I solved it. It’s embarrassing. I’ll update in a few minutes here.
MemberIn case it helps, here is the output from a $sys:
[fb] firmware build 440.14
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
[id] TinyG ID 3X3566-HDH
[ja] junction acceleration 3937 in
[ct] chordal tolerance 0.0004 in
[sl] soft limit enable 0
[st] switch type 0 [0=NO,1=NC]
[mt] motor idle timeout 2.00 Sec
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 1 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[js] json serialize style 1 [0=relaxed,1=strict]
[tv] text verbosity 0 [0=silent,1=verbose]
[qv] queue report verbosity 1 [0=off,1=single,2=triple]
[sv] status report verbosity 2 [0=off,1=filtered,2=verbose]
[si] status interval 250 ms
[ec] expand LF to CRLF on TX 0 [0=off,1=on]
[ee] enable echo 0 [0=off,1=on]
[ex] enable flow control 2 [0=off,1=XON/XOFF, 2=RTS/CTS]
[baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
[net] network mode 0 [0=master]
[gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
[gun] default gcode units mode 0 [0=G20,1=G21]
[gco] default gcode coord system 1 [1-6 (G54-G59)]
[gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 0 [0=G90,1=G91]MemberThe machine’s owner dug into his box of miscellaneous computer cables and found a USB A-B cable of just the right length. We plugged it in restarted TinyG. It jogged around fine. Ran half-a-dozen air jobs successfully. Ran a real job successfully. Ran a bunch more air jobs with no issues.
So it all came down to a bad cable. Nice.
440.14 is on the TinyG now. Chilipeppr and SPJS are the latest versions too.
The owner is very happy with the quality of the cut. I think his machine was running without micro-stepping before where we’re at quarter stepping.
He’s a little apprehensive about the TinyG and Chilipeppr being…more tightly linked to the hobbyist market than the manufacturing market. He is definitely oriented towards production and wants production-oriented features. But now that things are cutting, he’s pretty happy.
MemberAs I said in the “spotty” thread, I think a USB extension cable or some dust is at the heart of my issues. On a Linux laptop hooked up to the TinyG via a single USB A-B cable, I have no issues.
MemberI think most of my issues were due to a bad USB extension cable. I can’t say for sure yet, but I do know that using my Linux laptop which can be moved close enough to the machine that the extension cable isn’t needed, I’ve been able to jog around and run air jobs for quite a while with no issues. Moving back to the Windows machine results in issues.
I suppose it could be an FTDI driver issue as well.
MemberYes. 440.14.
This morning, I was able to get the TinyG configured to match this machine, but it still becomes unresponsive fairly often. Sometimes it runs for a bit, sometimes it hangs after only seconds. It is much worse than it was on the stock firmware (but other things have changed too).
My assumption is that there are many people running 440.14 on a TinyG v8 via Chilipeppr and SPJS on a Windows machine without problems. I’m not breaking new ground here, am I?
I’m about to repeat my testing on my Linux machine, which will rule out a USB extension cord and a dusty USB socket. But I’m running out ideas as to the cause.
MemberSo I’m going to stick with edge for the moment. For my use case, it seems to be behaving better. I’m a little worried about having to fudge the travel per revolution numbers, but as long as it works.
MemberPut edge back onto the TinyG. It’s moving!
MemberIt really doesn’t take much for the TinyG to become unresponsive. Just restarted everything (the TinyG, SPJS, and Chilipeppr) issued a $sys, then a G20, and it stuck.
MemberOn the Windows machine, running Chilipeppr and SPJS 1.80, the TinyG does eventually become unresponsive entirely. And I did notice that the TinyG Chilipeppr widget is reporting the version of the TinyG firmware as 0.7, when it is really 380.08.
MemberAnd if I had just read a bit farther on the firmware update page, I would have noticed that my problem was covered. Nice.
Added the -e option to avrdude. That seems to have worked. Blushing a bit here.
MemberBelieve it or not, shearing actually that stressful on the sheep. If they are held right, they just relax. I didn’t believe it until I witnessed it first hand. But I digress.
The TinyG is running FW 435.10.
tgFX is the latest (ie. last) version from GitHub. But I’m definitely moving away from it.
I had the lock-up problem mostly under Windows 7 running tgFX. I may have had the same issue under Linux, but now that I’ve looked at it some more, I’m no longer sure. If it was happening, it might have been the serial-port-json-server issue.I here you on tgFX getting stale. Just a matter of time.
MemberI’ll be sitting in front of the machine in a few hours and can answer all questions at that point. But before changing anything, I’ll use tgFX to do a couple of air runs of the job we ran on the 11th, just to see if I can get everything bunged up again. Then I’ll upgrade to the latest versions of the firmware, Chilipeppr, Chilipeppr’s serial port server, and give it a again.
At this point, I am pretty sure that we will be making the switch to Chilipeppr. The only thing holding me back was jogging issues, and a troublesome version of the serial port server, but those issues look to be resolved.
MemberSorry for the delay, but I was helping shear sheep yesterday. (No. I’m not kidding.)
I did my initial testing under Linux (Ubuntu 14.04). Whenever I have issues, the Linux machine gets used for trouble-shooting. Otherwise, a Windows 7 PC controls the TinyG. Can’t check the serial-port-json-server at the moment, but I downloaded it on March 9th, so… Probably 1.79.
The good news is that we did a successful run on a reasonably complicated job. We actually used TGFX. But before the successful cut, after several dry runs, we did a pass to score the waste board. During that run all motion stopped mid-job. The TinyG was unresponsive to console commands, TGFX wouldn’t disconnect, restarting TGFX didn’t help as it wouldn’t connect to the TinyG. We ended up power-cycling the TinyG (and external drivers). After using some compressed air to clear out all the USB connections, and hooking it back up, we successfully ran a couple air-jobs, and then the actual job, without problems. But with this sort of intermittent failure, I’m still nervous.
Next week, we’re going to attempt a job that will require repeatedly running a job. That will be a good test, and provide opportunities for potential fixes. I’ll try ChiliPeppr again too, with everything as up-to-date as possible.
-
AuthorPosts
