Hi and greeting from Italy. I'm writing this message on behalf of a friend who doesn't understand English. Here is the problem :
My friend works in a company that own a milling machine powered by a MELDAS 64 ASM controller. They are trying to send CAM data files from a PC to the CNC controller via RS232.

Transferring data from the CAM program in the PC to the CNC controller via RS 232 is a process that is having problems. The data is someway corrupted and the result is obviously a wrong operation.

The RS 232 settings we are using are :

7 data bit
2 stop bits
9600 baud
even parity
flow control : xon/off

The cable configurations is :


MELDAS 64 ASM PC

1 ------------------------------------------------- 1

7 ------------------------------------------------- 7

2 ------------------------------------------------- 3

3-------------------------------------------------- 2

4 ----- ------ 4
| |
5 ----- ------- 5

6 ----- ------ 6
| |
20 ---- ----- 20

The cable is only 10 feets long and so cable length should not be is not an issue.
a Technician suggested to use hyperterminal to transfer the Gcode using the same communication data parameters and a VT100 terminal emulation. I'm a computer consultant and after seeing the problem I suspect that the data flow control (which is done in softwtare via xon/xoff) could be the problem.

Software flow control made via Xon/xoff is not affordable and I think that the parameters data could be wrong. Although we didn/t try, I think that lowering the baud rate speed woludn't be a solution because the files to be transferred are pretty big (in the 4 - 5 mb range) and the time requested would be too high.

To solve this problem in another way, an expansion board for the Meldas 64 ASM capable to support flash cards has been bought. The part # for this expensive board is FCU6 EP203 (or at least this is the item # quoted in the invoice). The technician was not able to make the MELDAS 64 ASM recognize this expansion board and so the flash card can't still be used. Does anyone had the same problem ? Which is the correct procedure to let the controller recognize this board ?

Do you have some idea about how to solve this ? Further info about the controller are : Part # FCU6 - MU032 version B with sw BND 39w000 rel. C5.

Many thanks for you help.

Sandro

PS: We have been told that there is s a big difference between Meldas 64 and Meldas 64 ASM. Is this true ? One more thing... please ignore my english errors my italian i s far better.

Sandro: Your English is much better than my Italian!

We've found that the Mitsubishi and Mitsubishi-made Meldas controls are unusual in that they must be set to use 8 data bits and even parity when the PC is set to use 7 data bits and even parity.

Normally, this would not make much sense becase 8 data bits with one additional parity bit is 9 bits, but I think this is just a difference between how Mitsubishi uses the term "8 data bits".

In any case, try setting the Mitsubishi to 8 data bits and leave everything else the same. Keep the setting on your PC at 7 data bits and even parity

Your cable wiring is a bit unusual, but it should work OK.

Hope this helps.

Sandro, I will send a PM with a Mitsubishi support contact that should be able to help with the Card issue.
Also with the RS232 problem, I would try a transfer from C64 to PC and also try 4800 baud with a small program to see if a difference exsists.
Al.

Sandro,

I recently solved a similar problem that had plagued me for a long time. While trying to DNC to a Meldas M50, I would receive intermittent P460 TAPE I/O ERROR. I tried different DNC software, but I experienced the same problem with all of them. So I decided to write my own DNC software, and that's when I realized what the problem was.

The way the M50 handles the DNC is this (and I think the M64 is no different): When it's receive buffer is low or empty, it sends the XON character to tell the PC to start sending. And when it's receive buffer is almost full, it sends the XOFF character to tell the PC to stop sending. So far, this is nothing unusual. What I found was that the M50 doesn't send the XOFF character until the receive buffer is very close to being full. Something in the area of 8 characters. This in itself doesn't cause problems, it's actually the DNC software on the PC that causes the problem. I found that most DNC software WILL NOT STOP SENDING IN THE MIDDLE OF A BLOCK. So even though the PC received the XOFF character, transmitting continued until the block was finished. And with the M50's receive buffer almost full, this would cause the P460 error if the block was long enough.

So my DNC software was written specifically to avoid this problem, and works great on the Mitsubishi controls. If you want to try it, it's included with NCPlot beta 20:
www.ncplot.com

Regards,
Scott

Scott is right. The Meldas controls require that the PC software stop sending very quickly when the Xoff handshake occurs. Fanucs also have room for only 10 characters after the Xoff, so they're a problem for many DNC programs too.

With many kinds of Windows DNC software, you can improve handshaking performance by setting the "FIFO buffer" in the Windows Control panel to a lower setting. Here's the procedure for Windows 2000 and XP:

Start button, then SETTINGS, then CONTROL PANEL
Double click the SYSTEM icon, then HARDWARE tab, then DEVICE MANAGER
Double-click on PORTS COM & LPT to expose the list of ports under it
Right-click on the COM port you are using for DNC, then select PROPERTIES
Click PORT SETTINGS then ADVANCED

Set the "Transmit buffer" slider to a lower setting (to the far left, or maybe one notch up from the left is OK).

Click OK to exit all menus and try the DNC operation again. This will only help if you're getting "Buffer overflow" alarms on the CNC.

Like Scott says, some DNC software is better than others in this respect.

Sandro: Your English is much better than my Italian!

We've found that the Mitsubishi and Mitsubishi-made Meldas controls are unusual in that they must be set to use 8 data bits and even parity when the PC is set to use 7 data bits and even parity.

Normally, this would not make much sense becase 8 data bits with one additional parity bit is 9 bits, but I think this is just a difference between how Mitsubishi uses the term "8 data bits".

In any case, try setting the Mitsubishi to 8 data bits and leave everything else the same. Keep the setting on your PC at 7 data bits and even parity

Your cable wiring is a bit unusual, but it should work OK.

Hope this helps.

Thanks for your suggestion Dan. I'm quite surprised to know that Mitsubishi could use 8 bit as 7 ! :cheers: But, anyway.. everything is possible. I will try your suggestion.
I will keep 7 bit even parity on the pc and I'll set 8 bit on the Meldas.

About the cable wiring... it was suggested by the Italian Mitsubishi support team but I'm not sure if they really know what they are doing. Meldas controls are not so common here in Italy and may that Mitsubishi guys simply send me the first document they found after a search in their internal database (if they have one).

The same was true about the software to be used. Mitsubishi simply suggested to use Windows HyperTerminal that as you know is not the best program to use to tansfer data to/from external devices via rs232.

Sandro

Hyperterminal is a pain, see here for a free program http://www.cadem.com/ncnet/ncnet_dncdetails-41.htm as well as cable and parameters.
I find the three-wire cable best with Meldas, with 4-5 & 6-8-20 jumpered out each end, no connection for the jumpered pins from end to end.
Al.

I am having the same problem on an older Mitsubishi machine. This machine runs a Meldas 300 series controller.

I can get dnc to initiate. It even pauses and resumes, a couple of times. Eventually, and always at the same place only about 30 lines in, it will give me the P460 Tape I/O Error.

I have set the machine up for software handshake, then hardware handshake, and tried various cabling options. I've set the FIFO mode off on my COM port, which did help the problem, but only moved the position where the I/O error occurs to later in the file. Nothing I seem to try fixes the situation.

Cabling is set up as follows (currently):

2-2
3-3
5-7
7-5
4-8
6-8-20 4-9