Home › Forums › TinyG › TinyG Support › coolterm not sending all gcode
- This topic has 45 replies, 4 voices, and was last updated 12 years, 3 months ago by roberlin.
-
AuthorPosts
-
July 22, 2012 at 8:35 pm #3382nmanousosMember
Thanks! I have a sherline mill. Yes – 25.4 thread per inch. (http://www.sherline.com/dimen.htm)
I tried changing the status report to 200ms, 300ms, and turning them off completely – but no change. It never makes it all the way through.
July 22, 2012 at 9:00 pm #3383nmanousosMembersuccess!!! in coolterm i changed the transmit options. I turned on “Use transmit line delay” and set it to 1000 ms. I am going to do a few more tests at lower line delays to see where it stops.
July 22, 2012 at 9:33 pm #3384aldenMemberCongrats. This sounds like a driver problem to me. THe XON/OFF is not being handled correctly. The host drivers might warrant some more attention.
July 22, 2012 at 9:36 pm #3385nmanousosMemberwhat version of FTDI VCP driver are you using? I am using 2.2.17, but I just found 2.2.16 and may give it a try
July 22, 2012 at 9:59 pm #3386nmanousosMemberAlden, you are right. I just installed the FTDI VCP driver v 2.2.16 and everything works. No need for line delays and I can feedhold now! A suggestion for the configuration page – mention to not use v2.2.17. Thanks for all the help!
July 23, 2012 at 7:56 am #3389aldenMemberThis is good news, but it’s also bad news – if the 2.2.17 driver is broken. How did you get 2.2.16? I had to hack the URL. Did you?
I will want to test this before changing the config page. I have 2 laptops that I use, an the one I’m on right now has the 2.2.17 driver in my “sources” directory, and I have no way to test what is actually loaded as it appears that the USB listing in the system profiler doesn’t show a driver unless it’s activated – which I will not be able to do for the next week due to travel.
In the mean time, happy cutting.
UPDATE: I had to run home. Here’s what’s in my system profiler under FT232R USB UART:
Product ID: 0x6001
Vendor ID: 0x0403 (Future Technology Devices International Limited)
Version: 6.00
Serial Number: A5014Y93
Speed: Up to 12 Mb/sec
Manufacturer: FTDI
Location ID: 0xfa122000 / 10
Current Available (mA): 500
Current Required (mA): 90
No indication of driver revision other then “Version” that doesn’t seem to correlate to the driver rev. How did you determine your driver revision?
- This reply was modified 12 years, 5 months ago by alden.
July 23, 2012 at 3:49 pm #3391nmanousosMemberYeh – I just changed the url to get 2.2.16 also. I don’t know how to verify the installed version either, I just reinstalled the 2.2.16 package – and now everything works.
September 1, 2012 at 3:44 pm #3448roberlinMemberSo, I had been experiencing similar issues as above but kind of intermittent. They’ve now worsened to the point where I’m basically unable to use the tinyg. This was with coolterm on a macbook pro, but also in other settings as I detail below.
I tried rolling back the FTDI driver to 2.2.16 and it didn’t do anything for me. Also tried tgfx and windows coolterm in bootcamp, and coolterm for linux on a netbook. All of them just sort of stall out in the middle of sending the file, and it happens with about everything I send at it now (everything is generated with cambam). But it doesn’t always stall at the same place and occasionally it will actually make it through the whole file.
I was wondering, does tgfx use the xon/xoff flow control also, or something else? (i.e. like the grbl g-code senders).
EDIT: to be more specific on what happens when it fails, with linux coolterm it pops up some dialog box about serial port error or “serial port disconnected” or something like that. With the mac coolterm, it usually just freezes up (although one time I sat there and watched as the percentage of file sent kept going up while it was indicating xoff in coolterm and tinyg was doing nothing).
- This reply was modified 12 years, 3 months ago by roberlin.
September 1, 2012 at 7:08 pm #3450roberlinMemberWell, I no longer think my current problem is due to software.
After running the file a dozen more times (at 12 minutes a pop) it seems to make it through the file if the spindle is off
and stall out if the spindle is on (although I don’t actually have it cutting anything to eliminate the variable of load on
the motors).
I moved the power cable for the spindle (a proxxon) as far away as I could and it didn’t make a difference.
Hmm….September 1, 2012 at 8:35 pm #3451aldenMemberWe’ve noticed this as well. It looks like interference between the noisy spindle and the computer – in particular the USB port. What type of computer are you running? Riley had a similar issue with his Panther and things work fine on one machine (Mac) and poorly on another (Dell laptop). We are still trying to work out how to isolate this. The best solution is to make the spindle less noisy. To that end we are trying some capacitors and varistors for spike clamping. Do you have separate AC circuits you can run the computer and spindle on?
September 1, 2012 at 10:37 pm #3452roberlinMemberMost of this has been on a 2.5 year old macbook pro 13 inch.
I am pretty sure I was hitting the same driver issues as above also, further complicating the matter.
But the rest of the testing will be be booted into windows and sending the file via tgfx.On the shapeoko forum they suggested that the contribution from the spindle might be vibration rather than EMI.
I am going to run it with the spindle handheld instead of mounted on the machine to try to distinguish.September 1, 2012 at 11:01 pm #3453roberlinMemberhmm… ran it with the spindle on in my hands and following as close to where it “should be” as possible and it actually made it all the way through. This would seem to suggest vibration.
But I can’t seem to get it to stall by jiggling stepper motor solder joints or other electrical connections…September 2, 2012 at 10:14 am #3456ril3yKeymasterRoberlin,
I imagine your vibration issue is really an EMI issue. When you held your spindle did you also make it further away from your controller?
I have a Panther CNC PCB mill with a Chinese spindle. The thing make a ton of EMI. When I hook up a dremmel or a DeWalt trim router… NO problem. A few things to try.. Can you power your computer + tinyg on a different circuit that the circuit your spindle is on? Easy way to check this is to turn off the breaker that your computer is on… The go back and find a close circuit that is still hot. Use that as a power outlet to drive the spindle. Try that.
If that works cool. If it does not there are a few things to try..
This is a really good article I found when dealing with this emi stuff. Its worth a read.
http://www.cnccookbook.com/CCCNCNoise.htmlLet me know how it goes.
ril3y
September 2, 2012 at 4:16 pm #3457roberlinMemberWhen I handheld the spindle I kept it within a few inches of where it should have been, but not touching anything, to try to minimize the distance difference. But it is possible my shapeoko is acting like an antenna, and the contact is necessary for that? 🙂
Anyway, I did some more testing and am leaning towards the emi as well. Like it was still stalling when I totally disconnected the tinyg from the shapeoko and moved it onto the concrete floor where it shouldn’t be getting any vibration. (was tracking progress via he graphics in tgfx).
I will get out an extension cord and try a different circuit like you suggest. And I’ll check out that link.
September 2, 2012 at 7:08 pm #3458roberlinMemberPutting it on a separate circuit did the trick!!
Since that isn’t a viable long term solution for me (only 1 circuit in my garage), I ran down to Radio shack and bought (per that link you sent’s suggestion) some of those snap on ferrite things. Put one on the power cable for the spindle and one on the USB cable, and it seems to be working properly on the same circuit.
It is really weird that the proxxon is causing this much trouble. Maybe I messed it up somehow.
Anyway, thanks for all your help, guys!!
-
AuthorPosts
- You must be logged in to reply to this topic.