Matsuura MC-760VX, Yasnac MX3 Serial Communications problems

Hello,
This is an extension of a previous trouble shooting on this machine.
I have got to the point where I am working on the communications to/from the Machine.

I have a laptop and have loaded Cadems NCLite DNC software

I have looked at the registers in the Matsuura to verify stop bits and baud rate and played with data bits.

The machine is setup only to use the 2nd RS232 port (doesn't seem to be an issue that I can tell) the 1st port is not enabled.

One thing I have not changed is the length of the RS232 cable...it maybe close to 30ft. The previous owner was using it so I haven't messed with it...but possibly an issue.

I have attached pictures of the machine port settings, the DNC software setting and the file received FROM the matsuura

Per a suggestion from other posts, I worked on getting the data out of the matsuura in the correct format, the picture attached is the output registers from the Matsuura.
Using the same settings I attempt to send a file to Matsuura. I get an error 077 which states '10 characters or more were read after stop code was issued'
It seems the machine and laptop arn't talking quite correctly.
I tried changing the hand shake method but on other settings it did not seem to work at all.

Any thoughts as to why I would be able to receive a file that looks correct but not be able to send one to the machine?

I have also attached the page from the manual that describes the parameter settings for the MX3. Maybe i am reading it wrong as well.

Thanks
David

Cooperstock said:

Hello,
This is an extension of a previous trouble shooting on this machine.
I have got to the point where I am working on the communications to/from the Machine.

I have a laptop and have loaded Cadems NCLite DNC software

I have looked at the registers in the Matsuura to verify stop bits and baud rate and played with data bits.

The machine is setup only to use the 2nd RS232 port (doesn't seem to be an issue that I can tell) the 1st port is not enabled.

One thing I have not changed is the length of the RS232 cable...it maybe close to 30ft. The previous owner was using it so I haven't messed with it...but possibly an issue.

I have attached pictures of the machine port settings, the DNC software setting and the file received FROM the matsuura

Per a suggestion from other posts, I worked on getting the data out of the matsuura in the correct format, the picture attached is the output registers from the Matsuura.
Using the same settings I attempt to send a file to Matsuura. I get an error 077 which states '10 characters or more were read after stop code was issued'
It seems the machine and laptop arn't talking quite correctly.
I tried changing the hand shake method but on other settings it did not seem to work at all.

Any thoughts as to why I would be able to receive a file that looks correct but not be able to send one to the machine?

I have also attached the page from the manual that describes the parameter settings for the MX3. Maybe i am reading it wrong as well.

Click to expand...

Hello David,
As you have parameters set for 4800 baud rate, you can use a cable, having a capacitance of 50 pF/ft, up to 1000ft long. Accordingly, your 30ft long cable is definitely not an issue.

You have parameter bits associated with the use of Control Characters (DC1 to DC4) set to Not Use (Xon = DC1 – Xoff = DC3); these are Software Handshake characters. Therefore, unless you’re using a cable configured for Hardware Handshaking and the Comms Software set to use RTS/CTS (Hardware Handshaking), which from your attached pictures it appears not, then these settings will cause the error 077.

Regards,

Bill

angelw said:

Hello David,
As you have parameters set for 4800 baud rate, you can use a cable, having a capacitance of 50 pF/ft, up to 1000ft long. Accordingly, your 30ft long cable is definitely not an issue.

You have parameter bits associated with the use of Control Characters (DC1 to DC4) set to Not Use (Xon = DC1 – Xoff = DC3); these are Software Handshake characters. Therefore, unless you’re using a cable configured for Hardware Handshaking and the Comms Software set to use RTS/CTS (Hardware Handshaking), which from your attached pictures it appears not, then these settings will cause the error 077.

Regards,

Bill

Click to expand...

Hi Bill,
Thank you for your reply, I am still trying to understand what it means for my settings.
What I am understanding is the following
1. cable length (assuming the capacitance) shouldn't be an issue
2. the Serial connector has to be wired for hardware hand shaking, so I may need to change the wiring...or I need to set the communications settings to go with the way the connector is wired.
3. Im not sure where you are seeing the control character (DC1 to DC4) settings. From the PDF page it looks like D5 in 6026 and 6028 are the "Control code sending command", and when set to 1 it does not send the control code. I don't know how to interpret this text related to what type of handshake it needs.

I do know this machine has been used before, So I am not certain I need to rewire for it to work. But I am willing to rewire the connection if needed. I would rather do it right, then 'make it work' if it wasn't correct before.

Thank you again for your input, I do appreciate having some direction.
David

Cooperstock said:

Hi Bill,
Thank you for your reply, I am still trying to understand what it means for my settings.
What I am understanding is the following
1. cable length (assuming the capacitance) shouldn't be an issue
2. the Serial connector has to be wired for hardware hand shaking, so I may need to change the wiring...or I need to set the communications settings to go with the way the connector is wired.
3. Im not sure where you are seeing the control character (DC1 to DC4) settings. From the PDF page it looks like D5 in 6026 and 6028 are the "Control code sending command", and when set to 1 it does not send the control code. I don't know how to interpret this text related to what type of handshake it needs.

I do know this machine has been used before, So I am not certain I need to rewire for it to work. But I am willing to rewire the connection if needed. I would rather do it right, then 'make it work' if it wasn't correct before.

Thank you again for your input, I do appreciate having some direction.
David

Click to expand...

Hello David,
To determine the pin out configuration of your cable (the cable between the control and your computer), remove the back shells from both ends, but at least from the DB25 Male Connector at the control end of the cable and note the wires that are attached and any pins that are bridged. The configuration for Xon/Xoff Handshaking (Software Handshaking) will be as follows:

Machine Side ---------------------------------- PC Side
DB25 Male Connector -------------------- DB9 Female Connector
1 -- Shield Trace ------------------------ Not Connected
2 ---------------------------------------------- 2
3 ---------------------------------------------- 3
4
| Bridged
5

6
|
8 All Bridged
|
20

7 ---------------------------------------------- 5

If your cable is configured as above, then the control and Comms Software should be set to used Xon/Xoff Handshaking

Whether Control Characters are used (characters for Xon/Xoff Handshaking) is set with bit 5 of parameters 6026-6027 and 6028-6029, depending on the Ports at the control being used. According to the pictures you attached to your earlier Post, these are set to Not Use these characters, but your Comms Software is set for Software (Xon/Xoff) Handshaking. Therefore, the Uart of your computer will be primed to use Xon/Xoff to control the flow of data, but because your control is set to Not Use these characters, this data flow control will never happen.

Regards,

Bill

angelw said:

Hello David,
To determine the pin out configuration of your cable (the cable between the control and your computer), remove the back shells from both ends, but at least from the DB25 Male Connector at the control end of the cable and note the wires that are attached and any pins that are bridged. The configuration for Xon/Xoff Handshaking (Software Handshaking) will be as follows:

Machine Side ---------------------------------- PC Side
DB25 Male Connector -------------------- DB9 Female Connector
1 -- Shield Trace ------------------------ Not Connected
2 ---------------------------------------------- 2
3 ---------------------------------------------- 3
4
| Bridged
5

6
|
8 All Bridged
|
20

7 ---------------------------------------------- 5

If your cable is configured as above, then the control and Comms Software should be set to used Xon/Xoff Handshaking

Whether Control Characters are used (characters for Xon/Xoff Handshaking) is set with bit 5 of parameters 6026-6027 and 6028-6029, depending on the Ports at the control being used. According to the pictures you attached to your earlier Post, these are set to Not Use these characters, but your Comms Software is set for Software (Xon/Xoff) Handshaking. Therefore, the Uart of your computer will be primed to use Xon/Xoff to control the flow of data, but because your control is set to Not Use these characters, this data flow control will never happen.

Regards,

Bill

Click to expand...

Hi Bill,
Thank you for the additional details. I will look at the connectors now to check wiring.
I can also try changing bit 5 of the appropriate serial port to use the flow control and see if that corrects the transmission.

Why does the data flow work from the machine to the PC with the settings? Is the PC more lenient about settings? Seems like it should be a two way street.
Thanks again
Dave

Cooperstock said:

Hi Bill,
Thank you for the additional details. I will look at the connectors now to check wiring.
I can also try changing bit 5 of the appropriate serial port to use the flow control and see if that corrects the transmission.

Why does the data flow work from the machine to the PC with the settings? Is the PC more lenient about settings? Seems like it should be a two way street.
Thanks again
Dave

Click to expand...

Hello Dave,
In really rough terms, when the Transmit/Receive Buffer becomes sufficiently Full or Empty a signal is sent (or received) by way of either a Control Character on the Transmit Lines, or Variation of Voltage on Control Lines. When sending data to the control, the control will send an Xoff (DC3 - Ascii 19) to tell the Sending Device to stop sending. Once enough data has been moved from the Buffer to storage, an Xon (DC1 - Ascii 17) is sent to the Sending Device to start sending again. This Handshaking continues until the end of the file being sent is reached.

If the rate the data is being sent is sufficiently slow that the data in the Buffer is always moved to storage before the threshold for sending an Xoff is reached, then in theory, no handshaking at all is necessary. The size of the Transmit/Receive Buffer of the PC is probably greater than that of the MX3 and the PC Hardware more efficient

Regards,

Bill

Cooperstock said:

...One thing I have not changed is the length of the RS232 cable...it maybe close to 30ft. The previous owner was using it so I haven't messed with it...but possibly an issue.

Click to expand...

Many people overlook the condition of the cable. Make sure it has zero pinches or kinks in it and take a good look at the ends for damage as well. If it is a custom made cable then take a really good look at the ends. (most people aren't nearly conscientious enough to make cables IMO) Watch where you are running your cable to keep away from high voltage and high RF noise sources. I've been told to make some loops of cable at each end to help keep noise down. We had one cable run that was super long but had much a higher baud rate than one of our short (twenty foot perhaps) cable that had to be in a high voltage/noisy RF area. Don't assume that because the cable worked before it will work in a different installation.

I recommend if you suspect any issues with it at all then don't hesitate to replace it and don't buy a cheap cable either. A loooong time ago we contracted a company to do some serial cable runs for us and we assumed they new what they were dong. It turned out they used the wrong spec cable and we ended up fighting all their cable.

If you really want to stay with a long serial cable and need to replace the one you have, I recommend a Grizzly cabling. It is by far the best I have used for rs232 applications because it is extremely resistant to interference and it uses slick, RJ45 ends. When you buy a cable you tell them what machine it's for and which flow control you're using and they supply the proper connectors which attach to the RJ45 connectors. They are multi shielded and claim to reliably run up to 300'.

Also, don't be hesitant to buy a lan cnc device if it suits your needs. You will rid yourself of long serial cables and have much more capability such as adding gigabytes of storage.

Qwan said:

If you really want to stay with a long serial cable and need to replace the one you have, I recommend a Grizzly cabling. It is by far the best I have used for rs232 applications because it is extremely resistant to interference and it uses slick, RJ45 ends. When you buy a cable you tell them what machine it's for and which flow control you're using and they supply the proper connectors which attach to the RJ45 connectors. They are multi shielded and claim to reliably run up to 300'.

Click to expand...

RJ45, really? Using as cable with RJ45 connectors simply introduces additional connectors and potential for further connector issues; at some point the RJ45 must interface with a DB connector to connect to the control and computer.

The standard has a clear answer to the maximum cable length. At a baud rate of 19200, the maximum cable length is 50 feet, or the cable length equal to a capacitance of 2500 pF. Accordingly a cable having a 50pF/ft capacitance is used in the standard. If for example UTP CAT-5 cable is used with a typical capacitance of 17 pF/ft, the maximum allowed cable length is 147 feet (for the max baud rate of 19200). If speed is reduced by a factor 2 or 4, the maximum length increases dramatically. The OP has the control and Comms Software set to 4800 baud. Accordingly, a 50pF/ft capacitance cable, up to 1000ft, could be used. Therefore, 300ft is rather irrelevant and 30ft infinitesimal.

Qwan said:

(most people aren't nearly conscientious enough to make cables IMO)

Click to expand...

Many simply hang their hat on the term "Null Modem" cable, not understanding that Null Modem is a generic term and refers to any cable where the Transmit/Receive lines are swapped end for end.

Often I've been called to resolve communication issues between CNC controls and PC, where the client swears black and blue that the cable is not the issue, because they bought an off the shelf Null Modem cable from a reputable supplier, only to find that the cable has no facility for Handshaking (either via the cable being a Loop-back Handshake Null Modem, or Full Handshake Null Modem Cable). Accordingly, I treat all cables bought off the shelf as being incorrect and make my own.

Assuming the OP's cable is configured as a Loop-back Null Modem cable, the control characters (DC1 and DC3) are transmitted on the same lines as the data being sent. His issue has been an Over-run error, not that no data at all is being transmitted, which would be more the case with a data line severed due to it being crimped.

The pictures the OP attached to his first Post clearly indicates that he has the Handshaking Methods between the control and the Comms Software mismatched; Hardware Handshaking at the control and Software Handshaking at the Comms Software.

Qwan said:

Many people overlook the condition of the cable.

Also, don't be hesitant to buy a lan cnc device if it suits your needs. You will rid yourself of long serial cables and have much more capability such as adding gigabytes of storage.

Click to expand...

Thank you guys for the input. I had decided to remake the cable. The PC side had Pins 7 and 8 jumpered. and on the Machine side pin 1 was not grounded/connected to the shield.
Not sure if it matters, but it appears a 15 wire cable is used, it appears to be a shielded 'serial' cable. I didn't see an issue with continuing to use that.
I have attached the pin connection as stated in the Yasnac MX3 manual. I had read in a couple other posts that people recommend to wire as per the Fanuc CNC serial cable. I found a diagram of this cable and its odd that it does NOT swap the TX and RX lines from the computer to the machine, is this a mistake?

It seems I should follow the MX3 wiring instructions although I would be glad to hear recommendations.
Thanks
David

Cooperstock said:

Thank you guys for the input. I had decided to remake the cable. The PC side had Pins 7 and 8 jumpered. and on the Machine side pin 1 was not grounded/connected to the shield.
Not sure if it matters, but it appears a 15 wire cable is used, it appears to be a shielded 'serial' cable. I didn't see an issue with continuing to use that.

Click to expand...

Hello David,
The cable you have and Posted pictures of in your last Post, is a Loop-back Handshaking, Null Modem (Xon - Xoff (Software Handshaking))Cable and is the same as the pin-out shown in my Post #5 with the addition of CTS (pin8) and RTS (pin7) bridged at the PC End. The bridging of CTS - RTS is not necessary at the PC end, but it will cause no trouble (leave as is).

The cable for the configuration you currently have requires no more than three wires. When making a Loop-back Handshaking cable, I use a cable with the minimum number of wires (but at least 3 of course), with a Shield trace wire.

The Shield Trace wire should only be connected at one end, preferably at the Control End. Connecting the Shield Trace wire at both ends can result in a Ground Loop when the two devices don't share a common Earth, or if the Earth for either, or both is not good.

As I have said a few times in this Thread, judging from the pictures attached in your first Post, the most obvious cause of your Over-run issue is that you have the Handshake Method set unmatched between the Control and the PC Software. Your pictures show the Control parameters to be set to NOT USE Control Characters, hence the Control is set to Hardware Handshaking and your PC Software is set to Software Handshaking.

With the Software Handshake cable configuration you're using (and there is no reason to not continue with this configuration, given that its worked for the previous owner), as long as you have a hole in your arse, with unmatched Handshake settings, or with both devices were set to Hardware Handshaking, you will experience grief. Resolving the hole in your arse will probably have no affect, so better to address the unmatched Handshake issue.

Cooperstock said:

I found a diagram of this cable and its odd that it does NOT swap the TX and RX lines from the computer to the machine, is this a mistake?

Click to expand...

The TX/RX pins of a DB9 connector is 3 and 2 respectively. The TX/RX pins of a DB26 connector is 2 and 3 respectively. Accordingly, when connecting a DB9 and DB25 connector, connecting 2 to 2 and 3 to 3, is cross connecting the TX and RX lines. When connecting two DB25 connectors, 2 to 3 and 3 to 2 is required to cross connect the TX and RX lines. Any deviation from this is a mistake.


Regards,

Bill

angelw said:

Hello David,

With the Software Handshake cable configuration you're using (and there is no reason to not continue with this configuration, given that its worked for the previous owner), as long as you have a hole in your arse, with unmatched Handshake settings, or with both devices were set to Hardware Handshaking, you will experience grief. Resolving the hole in your arse will probably have no affect, so better to address the unmatched Handshake issue.

Regards,

Bill

Click to expand...

Hi Bill, I wasn't ignoring your handshaking directions, I did try several configurations: Using the cables that came with the machine, I tired the following:

1. Bit 5 on (no control characters) with 'software' hand shaking set on PC side (config shown in the pictures)
2. Bit 5 on with 'Hardware' on PC side
3. Bit 5 on with 'Both' on PC side
4. Bit 5 on with 'none' on PC side

for the above configurations, when trying 2,3 or 4 above the PC says it sent the g-code but the machine reports nothing (sitting there listening, no errors)

I then set bit 5 to '0' and tried the same sequence and got the same errors.
I do not have the same PC/laptop the previous owner had, so I do not know what software he used. I guessed it wouldn't matter as it was just serial transfer. I did try using Hyperterminal on a different laptop but that didn't have any good results, using a DNC software made it easier to change parameters.

I plan on repeating the configuration test just to make sure everything was well connected and I didn't 'fat finger' one of the settings.
-David

Cooperstock said:

I plan on repeating the configuration test just to make sure everything was well connected and I didn't 'fat finger' one of the settings.
-David

Click to expand...

Hello David,
With the cable you have (a Loopback Handshake Null Modem), the only machine/PC software configuration that will work is:

1. For the control to be set to USE DC1 to DC4 characters.

2. For the PC Software to be set to Xon/Xoff (Software) Handshaking.

Don't waste you time with any other setting.

Does the PC you're using have a real Serial Port, or are you using a USB to Serial adapter?

If you continue to have trouble, purchase an RS232 Test Plug. They are not expensive and will show what is happening on the Transfer/Receive and control lines. With regards to what will be shown for the Control Lines, because the cable is a Loopback Null Modem Cable, RTS/CTS should be seen as On all the time.

Regards,

Bill

angelw said:

Hello David,
With the cable you have (a Loopback Handshake Null Modem), the only machine/PC software configuration that will work is:

1. For the control to be set to USE DC1 to DC4 characters.

2. For the PC Software to be set to Xon/Xoff (Software) Handshaking.

Don't waste you time with any other setting.

Does the PC you're using have a real Serial Port, or are you using a USB to Serial adapter?

If you continue to have trouble, purchase an RS232 Test Plug. They are not expensive and will show what is happening on the Transfer/Receive and control lines. With regards to what will be shown for the Control Lines, because the cable is a Loopback Null Modem Cable, RTS/CTS should be seen as On all the time.

Regards,

Bill

Click to expand...

Hi Bill,
I am going to try to get back to this machine tomorrow if time allows. The computer has a Serial port, I wanted to try to avoid an complications related to the data going through a converter to start with. I am pretty sure the port does work as the laptop is able to receive the settings output from the machine.

I just wanted to clarify to make sure I am understanding you correctly:
-I will leave the DNC software set to software handshaking
-For the Machine, since there is only one bit (#6026 -number 5 and #6027-number 5 depending on which input port is used) to turn on and off. Am I understanding you correctly that by changing bit 5 to '0' (which is described as 'sends control code') that now the Control Characters (DC1 to DC4) will be used.


It sounds like at that point, with Bit 5 set to '0' and the DNC software set to 'software', that if I still have trouble the trouble shooting would probably be hardware related. I have ordered the Serial testers, one for the DB9 and one for the DC25.
I'll report back how it goes.
Thank you for your patience and direction
David

Update:
I am finally getting back to this problem.

using the cable shown above:
Machine Side ---------------------------------- PC Side
DB25 Male Connector -------------------- DB9 Female Connector
1 -- Shield Trace ------------------------ Not Connected
2 ---------------------------------------------- 2
3 ---------------------------------------------- 3
4
| Bridged
5

6
|
8 All Bridged
|
20

7 ---------------------------------------------- 5


And the following settings

PC
4800 Baud, 7, even, 1 stop, software hand shake (xonXoff)

Machine
Using RS232 port #2 set to input and output
4800 Baud (bits 1001 for 6028)
1 stop bit
'Send control code' turned on

I still get the same message of error 077 which states '10 characters or more were read after stop code was issued'

I have purchase the DB9 and DB25 serial com tester boxes, Any chance you could tell me which lights should be 'mark' 'space' or off?
I can plug the db9 tester into the cable from the machine and the cable from the computer, but I am not sure how to interpret the lights, or what would indicate a problem.
Thanks,
David

Here is the tester plugged into the computer and machine at the same time

Officially i have tries the 3 wire cable with the machine and laptop set to the same settings and still get the error 077.
I am looking further into the serial communications signals to try to trace down if the correct wires are going to the correct places.
Also, i am going to slow down the baud rate to see if its related to that

Cooperstock said:

Officially i have tries the 3 wire cable with the machine and laptop set to the same settings and still get the error 077.
I am looking further into the serial communications signals to try to trace down if the correct wires are going to the correct places.
Also, i am going to slow down the baud rate to see if its related to that

Click to expand...

Just for shits and giggles. take the cover off your machine to expose the rs232 port on the machine so you can see the wires going to it. and see if they have been resoldered. ran into this a few times where people add jumpers or switch a few pin wires to the machine side so they dont have to play to cable configuration.

I rarely have problems with connections. usually its the software and parm setting problems. I'm not like most here I only use rj 45 connectors and my shop runs 100 foot cat 5 cables. I run at 4800 -9600 baud and if I get some garbage characters on the receive from machine end its generally a software error.
I'm running a old communicate v8.2 from 1996 on windows xp sp2

Delw said:

Just for shits and giggles. take the cover off your machine to expose the rs232 port on the machine so you can see the wires going to it. and see if they have been resoldered. ran into this a few times where people add jumpers or switch a few pin wires to the machine side so they dont have to play to cable configuration.

Click to expand...

I will look at that thank you.
I do have a DB25 serial signal checker.
It appears the Machine puts out RTS and DTR (Request to send and Data terminal ready) signals when I press the 'in' button to load code.
But with the three wire connection these signals do not go to the pc.

It appears that with the 3 wire connection the computer is just dumping the data to the machine. There is no way for the PC or the Machine to tell the other they are ready or to holdup.

Cooperstock said:

I will look at that thank you.
I do have a DB25 serial signal checker.
It appears the Machine puts out RTS and DTR (Request to send and Data terminal ready) signals when I press the 'in' button to load code.
But with the three wire connection these signals do not go to the pc.

It appears that with the 3 wire connection the computer is just dumping the data to the machine. There is no way for the PC or the Machine to tell the other they are ready or to holdup.

Click to expand...

Hello Cooperstock,
There is indeed and its called Software Handshaking. It does, however, requires that the RS232 Protocol Parameters of the Control be set correctly. Similarly, if a Hardware (Full Handshake) cable were to be used, the parameters of the Control must be set correctly for the use of Hardware Handshaking.

The Three Wire cable is a Loopback Null Modem Cable. RTS should be bridged with CTS. DTR should be bridged with DSR and DCT. The signal from DTR asserts both DSR and DCT. Accordingly, as far as the Control is concerned, all is ready to Send and Receive; an illusion of Hardware Handshaking has been created by the Loopback Bridging. The actual method used to have the External Device Send or Waite, is to send device control characters, DC1 (Xon - Ascii 17) and DC3 (Xoff - Ascii 19) along the same Transmit Data Line (TDX - pin 2 of DB25) as the data will be sent.

Therefore, if the parameters of the Machine Control are set to use DC Characters for Flow Control, and the External Device is also set to use Xon/Xoff (Software Handshaking), then there is no reason, except for faults with the control, or External Device, why the Three Wire system won't work.

Concentrate on ensuring all parameters at the control have been set correctly, particularly the use by the control of DC Characters for Flow Control and that the settings of the control are matched exactly in the External Device Software.

Regards,

Bill

angelw said:

Hello Cooperstock,


Concentrate on ensuring all parameters at the control have been set correctly, particularly the use by the control of DC Characters for Flow Control and that the settings of the control are matched exactly in the External Device Software.

Regards,

Bill

Click to expand...

Ahhh, it might be starting to get through my thick skull. lol

Setting the Machine to 'Use control characters' and the software to 'Software handshake' allows all the control to be coordinated through the TD and RD (pins 2 and 3).

Pin 7 DB25 connected to pin 5 DB9 is the ground reference for these signals.

The machine is set to use 'send control codes' but does that mean it is using the correct codes for the laptop? I do not see any way to configure or specify the control codes that the machine is actually using.

I will double check the loop backs.

Also, I know grounding loops can cause issues. The shield of the serial cable is tied to the ground (pin 1) of the DB25 connector. Is this the correct method? The shield is not connected to the laptop side. the only 'ground' is the pin 5 coming in for the serial data.

Is there a way to find what the parity should be set to? or will that just be trial and error once I start getting data?

Final question for today: Do I need the EOB ';' character at the end of each line of the text file to be uploaded? I have added it but not sure if it helps or hurts.

I am uploading a simple 3 line code that just sets the basic machine setup. Its longer than 10 characters.