Drip Feed Issues

[drafting3]

I run a 3 axis SNK-FSP50v. It was built around the time I was born, and has about 32kb of on-board memory.

 

I've been doing some amazing 3D toolpath work with it mainly because I've been drip feeding my programs.

 

 

 

However, since the time I built a new computer I cannot get the drip feed to work properly. I've tried drip feeding 3 times, and have had 3 crashes. For some reason random lines of code are not being sent to the machine. Usually the G0 command to retract out of a hole before moving the next hole is being left out. My code is fine, and when I send smaller programs to the machine's memory, they run perfectly.

 

 

I'm having some sort of issue with communications between my computer and the machine.

 

 

I've checked all my port settings (USB to serial), and all my settings in CIMCO match what i was using on the previous computer.

 

 

Any ideas?

[jeff]

Have you gone into the port settings itself in the Device Manager and made sure they are the same?

Maybe try UNchecking FIFO Buffer in the advanced port settings?

[drafting3]

those settings match what was on the last computer, which includes a checked FIFO buffer.

 

i'll have to play around with it when i'm not on a deadline i guess... (whenever that will be... probably the next time I MUST drip feed something... :/ )

[uncle_dolan]

are you using shielded eternet cable to transfer your programs?

[Chris Rizzo]

However, since the time I built a new computer I cannot get the drip feed to work properly.

 

so your old rig worked ok?

 

Usb to serial cards I've seen be of very sketchy quality.

B & B electronics have some very robust products.

 

Make sure everything is grounded very well. Slow down the baud and see what happens for starters.

[Chris Bloedorn]

Make sure your usb to serial does not have the prolific chipset....unreliable.

 

Use the FTDI, it works well....

[drafting3]

are you using shielded eternet cable to transfer your programs?

 

Yes

 

so your old rig worked ok?

 

Usb to serial cards I've seen be of very sketchy quality.

B & B electronics have some very robust products.

 

Make sure everything is grounded very well. Slow down the baud and see what happens for starters.

 

Yeap. Drip feed worked flawlessly with the old computer. I have the exact same setup as before, with the exception of a new computer. All my settings match that of the old computer. Baud rate is set to 4800. (wouldn't transfer at all at 9600)

 

 

 

Make sure your usb to serial does not have the prolific chipset....unreliable.

 

Use the FTDI, it works well....

 

It is prolific, but it worked fine before.

 

Not sure what's happening here. I've been swamped, so I haven't had a chance to mess with it. This issue has still not been resolved.

[drafting3]

So, I've decided to purchase a serial I/O card.

 

http://www.sybausa.com/productInfo.php?iid=707 is what i went with because of great reviews and an afordable price.

 

Does anyone know what settings I need to use in Cimco?

 

 

I'm currently set as:

 

Stop Bits: 2

Parity: Even

Baud: 4800

Data Bits: 7

Flow Control: Software

Enable DTR

Enable RTS

XOn: \17

XOff: \19

 

CR/LF: \13 \10

Remove ASCII O's

[RayD]

I have wired well over 1000 machines for DNC, both wired and wireless, Ethernet, ftp, directory sharing.. the works. I can say 1000% the USB to serial is not reliable for Drip feeding.

 

You should be ok with the serial PCI card, the Cimco editor port does not nearly the amount of setting as the DNC-Max solutions so not as many options to try.

 

Start by setting the Transmit tab to the same settings as the machine baud, stop, parity , etc... on the transmit tab set "Delay before each line(ms)" to 3,and work your way up from there.

 

This helps your CNC buffer to read each line in before receiving the next.. how long it needs to be depends on your cable quality, length, serial device interference, where and how you routed the cable(near power lines) lots of reasons code can be dropped.

 

Edit * Hardware handshake is more reliable but you need the correct cable wiring and not all machines support it

[Sticky]

I prefer hardware handshaking as well. Here is a diagram to set it up:

 

 

[drafting3]

I have wired well over 1000 machines for DNC, both wired and wireless, Ethernet, ftp, directory sharing.. the works. I can say 1000% the USB to serial is not reliable for Drip feeding.

 

You should be ok with the serial PCI card, the Cimco editor port does not nearly the amount of setting as the DNC-Max solutions so not as many options to try.

 

Start by setting the Transmit tab to the same settings as the machine baud, stop, parity , etc... on the transmit tab set "Delay before each line(ms)" to 3,and work your way up from there.

 

This helps your CNC buffer to read each line in before receiving the next.. how long it needs to be depends on your cable quality, length, serial device interference, where and how you routed the cable(near power lines) lots of reasons code can be dropped.

 

Edit * Hardware handshake is more reliable but you need the correct cable wiring and not all machines support it

 

I don't think the cable is what caused the problem as it was the same cable that worked fine before, but I've set the delay to 5ms for now. I'll check it the next time I have a program to run. Is there a "max" this should ever be set to?

 

Attached is a picture of one of our cables that shows the wiring. I believe this is called a non-parity cable, which doesn't allow for handshaking, right? Should I set handshaking to <none>, or leave it as software?

[RayD]

There is no "max" for delay, the higher you set it the slower the program will dump into the control, up-to any timeout value the control might have set.

 

3ms should be enough as you are running at a low baudrate.

 

My guess is that cimco was dumping code in faster than the buffer could handle it, so some code was dropped (Not supposed to happen but can with software)

 

your cable is wired for software

 

software handshake is better than none, but not as good as hardware.

 

None = no checking if code is received

Software = code is sent to confirm code is transferred (If code is dropping it can miss these confirmation codes)

Hardware = Voltage is sent to confirm code transfer using the extra wires in the cable (most stable and reliable but not all controls can handle this properly)

[drafting3]

Thanks. The next program I'm going to drip feed is contouring combustion chambers for the owner's race car engines...

 

I'll probably do a test run before I actually start making chips...