What's new
What's new

Shadow / Bandit CNC Trailing off!!

maximum11

Plastic
Joined
Dec 10, 2009
Location
Roanoke, VA
My shadow CNC controller wants to trail off from the part and go elsewhere when running program from external device. Works fine when same program is executed from ram.
Any body got any ideas?
 
Check the manual but I think the baud rate for DNC is lower than for uploading full files: 1200 baud versus 4800. Because you must rely on hardware handshake, you need to use a short cable, with a shield grounded at one end only.
 
Because you must rely on hardware handshake, you need to use a short cable, with a shield grounded at one end only.

What has cable length and shielding got to do with hardware handshaking?

The baud rate argument makes sense. Your standard PC serial port will continue to spew up to 16 characters after it has been told to shut up; this can cause problems too.
 
What has cable length and shielding got to do with hardware handshaking?

The baud rate argument makes sense. Your standard PC serial port will continue to spew up to 16 characters after it has been told to shut up; this can cause problems too.

A long cable has a chance to pick up interference.

Hardware handshake requires voltage control on two pins to turn communication on and off. A long cable has too much capacitance for this to be reliable 100% of the time. BTDT.
 
Hardware handshake requires voltage control on two pins to turn communication on and off. A long cable has too much capacitance for this to be reliable 100% of the time. BTDT.

The handshake signals are going to operating at a frequency that is at most 1/10th of the baud rate. Any capacitance caused by a long cable is going to wreak havoc on the higher frequency data signals long before it becomes a problem to the flow control signals.

I don't disagree that a problem you had in the past may have been resolved by improving shielding or shortening a cable, I just think that there is a chance that your reasoning on the source of the problem isn't quite congruent with reality.
 
I suppose before we go any further, how long is long?

Hu Flung Dung... Any relation to Hao Long?
 
Back when I was running the Shadow from my office computer, I had a cable length of about 35 to 40 feet. After a few of these inexplicable errors (with the tool meandering through the part because one coordinate was dropped :( ) I shortened the cable to a 6 footer and ran from a laptop right beside the control. Never had the problem again.
 
Hu,
I'm wondering of the laptop had less of an output buffer (configured), and did not continue to overflow the machine after it got the handshake.

Had the same problem with a Bostomatic, and a BTR emulator. It ran fine for about XXX lines fo G-Code. Then it must have failed to handshake in time, missed a few commands, and continued on to the next G-Code.. Unfortunately the machine took the shortcut to that next G-Code when it finally seen it.
 
3t3d,
If the port was configured differently on the laptop, I didn't do it, but it could have been, I suppose. I was running short segment 3d code at the time, so there was a lot of data transfer with very little time delay permissible.
Now I'd be willing to forgive a mistake or two, but the dang cnc doesn't look at things the same way :D
 
RS-232 is an unbalanced data transfer protocol. The signals are referenced to a common ground. In a high noise environment like machine tools this setup can cause all kinds of unexplainable errors, reality has no bearing here.

I believe the max length on an RS-232 cable is only 50 ft under good conditions and this is not a good condition. Try driving it with a shorter cable like 6 or 10 feet to eliminate a cable problem. If it is a cable you can try a double shielded one, convert to EIA 422 or better yet use an optical cable.
 
Still got problems

I've tried every grounding config and every data transfer rate and get the exact same errors everytime when downloading to the machine. (I gave up on dnc for now, until I get a reliable transfer to occur)
Any ideas what would cause the exact same bits to get dropped, or changed, every single time a transfer takes place?
 
Does the controller ever halt with any kind of error message when it comes to a bad line of code or does it just keep on moving? Have you tried transmitting with a different PC?

One other thing which I have witnessed is bad characters in large gcode files. This seemed to be a Windows bug of some sort. Every line in your gcode file normally ends with inivisible machine characters representing Carriage Return and Line Feed. Inexplicably, Windows puts two Carriage return characters together at the end of some lines in the file. If you load the file into Notepad, and scan down through it, you can sometimes find two lines of gcode run together as if they were one long line. But this is difficult to detect this way, let alone fix.

I used a free hex editor to examine the gcode file.
Freeware Hex Editor XVI32

You can load your gcode file into the hex editor and use its search function to locate any instances of bad characters. Search for the bad combo using the terms:
0D 0D
If any of those characters are found as a pair in your file, those are bad lines. The legal combo is
0D 0A

So you can use the search and replace function in the hex editor to fix all instances of a bad combo in your file.

I have also seen Windows add the bad combo into the file when it is copied from one medium to another. This drove me nuts for a while with my Haas, because the file would check out ok on the hard drive, and then be bad on the floppy, so the actual file had to be inspected on the medium it was saved on before it was uploaded to the machine.

I never saw this error on smaller gcode files, but anything that was a meg or two large needed to be checked.
 
data transfer

Yes I do get errors (estop pressed, axis limit, bad contour or bad parameter), sometimes none.

Sometimes it trails off into space (or the part), sometimes the code halts and locks up with no error (have to restart the controller).

The code is fine in the pc (have 2 pc's tried so far, will try a 3rd tommarrow).

What shows up in the machine are lost characters, meshed lines and newly created parameters like /z-277.0 (that was fun to clean up)

If I manually go into the shadow after a download and replace the bad lines with what they are supposed to say (according to notepad), as I go through the dry run, the programs will run.....eventually....once everything is fixed.

I think I'll try to make another cable too, although the one I have ohms out fine. The grounding and shield are as prescribed.

I also noticed that with dnc and download, the errors are more common with slower transfer rates.

Todays program isn't big (1000 lines).
 
I guess we never have seen how you are setting the communication parameters in your communications software and on the Shadow, and what software you are using to transmit.
 
typical settings

1200 baud, 8, 1, none, hardware.
Settings are same in shadow, in port config on pc and in "shadcomm" (the download software). Cable is about 6 or 7 feet.
 
That looks ok. As far as I know, the cable either works or it does not work, there is no halfway working unless you have an intermittent connection.

There are two types of hardware control, and you need a ground on pin 5 plus pins (2 and 3) or (7 and 8) hooked up to cover both types if your comm software doesn't tell you which type it is using. It would do no harm to have all those pins properly connected.

With regard to miscellaneous error messages from the control, that is unusual for them to occur without a good reason.

Have you contacted Len Albright at Control Solutions in Bozeman? Maybe he'll have some ideas. There is an EEPROM reset procedure (I forget what the exact sequence was) that maybe he could run you through. You should have a paper copy of all the settings before you do this. Perhaps there was a problem with some of the firmware and he might advise a new chip with the latest and greatest fixes.
 
Gcode???

OK, I've got it narrowed down...I think.

Check this out, I can run a 5.5 meg file with no problems. The same file will run over and over again, no problems.

I can switch over to a file that was giving me trouble and I get errors.

I can manually write a short 25 line program in note pad and it will give me errors.

I can switch over to a 1 meg file and it will run, switch to the 5 meg, it will run.

Go back to any file that makes trouble, it will not run.

This 'appears' to show that the comms are right, the machine is fine, the pc is fine, the cable...etc. (5.5 megs took about 18 hours to run with no errors, the thing must work, right?)

Looked at 2 bad files in 'hex', no errors, all the carriage returns are in place. No search results for 0D0D.

I talked with Len via voicemail, but when we last talked the machine was running a good file, so I told him everything was fine, then yesterday it started giving me trouble and here I am. Still have yet to get back with him.
 
more news

I just downloaded the tiney file and it's running. But would run in dnc mode.
Is there something to do with the file size?????
 








 
Back
Top