Baud Rate not accurate

[DW_Microsys]

I'm using T100MD16x16 with Maple 5056T HMI. I was using RS485 and encountered big problem with lost communication - it happened every 2-3 minutes. Then I switched to RS232 and it works much better, but I still get communication error from time to time, though it can pick up within 1 second.

I tried:
1. Fix the protocol to MODIBUS RTU
2. Set response time to ASAP.
3. Re-Set baud rate - this helps a lot for the response time. Suppose the port baud rate is 38400 by default. The PLC will response to HMI in about 30ms delay. After I re-set baud rate to 38400 in custom fuction, the response time reduces to 4ms!!!!!! Strange! I believe this is a software bug.

I also notice the baud rate on PLC side is not accurate. With an oscilloscope I found the bit width from HMI is about 26us, which is correct; however, the signal from PLC side is about 28us width, which is too far away from what it should be.

Thanks in advance for your help.

[support]

T100MD1616+ should run very well at 38,400bps. In fact if you program the PLC and put it in online monitoring by default it runs at 38,400 and you can use online monitoring at 38,400 bps without problem. I believe the baud rate error is less than 2% which is well tolerated by any UART communication device.

Did you download the Maple OIT sample project? It could be some settings issue with Maple. By loading the sample project into Maple and put a blank program inside the PLC you can test the comm under the most ideal condition to see if it works well. If so then you can test with your PLC's program to see if it works. Note that if your program accesses EEPROM a lot it can cause COMM error because the CPU shut down interrupt during EEPROM access to prevent corruption of the data.

[DW_Microsys]

Thanks for your reply.

I have no problem with online monitoring, even though sometimes it seems "lost" communication for about 0.5s and then recover by it self.

I tried the OIT sample projects, both on 485 and 232. If I repeat pushing the button, some times the PLC will response slowly - about 1 second no response.

Again, with monitor the communication with ocilloscope, I found these two things. In both case, I'm using RS232 port and HMI is master, PLC is slave; also, I'm using a very simple PLC ladder circuit, basically it turn the outputs (Stack lights) based one the relay status; HMI will toggle the relay on/off and display the output status. No communicaiton command, no EEPROM access.

1. PLC response delay.
     If I use default setting, i.e. do not use setbaud 1,6,   but do use setprotocol 1,1 and setsystem 3,0, the PLC will response the HMI command after 30ms.
     However, if I re-set the baudrate by setbaud 1,6, which suppose no change to the baud rate setting, the PLC will response the HMI in about 3-4 ms.
     I'm thinking this is a bug in PLC OS.

2. Baudrate accuracy.
    I checked the signal again with ocilloscope. The problem is still there: transmitter signal from HMI is 26us bit width, while PLC transmitter signal is 28us bitwidth.
    By monitoring the command/response signal, I can tell that every one or two minutes, the PLC will stop response for one command cycle, i.e. you can see the HMI send command to PLC, but PLC no response. With RS232, most of the time the HMI will pick up the communicaiton in about 1 or 2 command cycle, so you don't notice the lost communication; but in some cases, it will lost communictiaon for more than 2 seconds, which is not allowed for my project.
 
I'm assuming the PLC uses HC12 CPU. I notice the PLC is using 16MHz crystal, which means the MCLK is 8MHz. I highly suspect that in the PLC OS, when setting the baudrate control register, it uses 14 instead of 13, which caused the bit width become 28us. I highly recommand that you ask your engineer to test this.

Next Monday I will double check the signal on RS485 port, to find out the bit width on 485 port.

Thanks for your support.

[support]

How did you measure your bit time?

We have created a simple test program where we send out "U" character repeatedly (which will form a nice square wave) from COMM3 (RS485 port)  and captured the wave form using a digital storage scope. The bit time we saw was 26us and the measured frequency of the wave form was 19.23KHz as shown in the following picture.



This means the bit rate is 2 x frequency of the square wave = 38460 Hz. The % error is small and within acceptable limit.

Could be it that your RS485 IC is slightly impaired that is giving you some trouble? If you have any 75176 or SN75HVD3082 you can try replacing the chip and see if you get a better comm result. We do have a Maple System OIT here and we tested it with 38,400 bps regularly without problem.

The PLC by default inserts a wait time of at least 10ms after it receives a host link command before responding. This is to give an auto-turnaround type RS485 driver (like that of Auto485) some time to switch over the RS485 driver. If you execute SETSYSTEM command to make it respond as fast as possible then it will not insert the extra waiting time but will respond typically right at the end of the ladder logic and I/O scan.  SETBAUD 3,6 would change the baud rate but should not affect the turn around time. I believe what you thought you have observed could be due to a confusion of the sequence of the command execution of SETSYSTEM and SETBAUD commands.

[DW_Microsys]

Thank you for your quick reply. I managed to did some more test yesterday, here are the summary.

1. The bit width: you are right, I tested in the way you described in your post, the bit width is 26us. It was the data pack width confused me. Baud rate 38400, 1 start, 8 data, 1 stop, HMI gives the following data pack (260us width)


While PLC gives the data pack of 284us:


Looks like the PLC gives 2 stop bits instead of one.

[DW_Microsys]

2. I hook up the HMI to PLC via COMM3 RS485 port and get the following results:

(1)Default Setting:   IN PLC, use power-up default setup, i.e. the RS485 will be 38400, 1, 8, 1, auto. DID NOT use any of the following commands: setprotocol, setbaud, setsystem.
The PLC response to HMI command typically 30-60ms. See the following picture.


(2) Use ONLY setbaud command: SetBaud 3,6, which means no change to RS485 port setting. The PLC will response to HMI typically 3-10ms, see the following pictures:




You can see, the PLC response much faster then before, even though I didn't use Setsystem command.

(3)Use Two commands: Setbaud 3,6 and SetSystem 3,1
Suppose the PLC will wait at least 10 ms before response to HMI. However, the PLC response time varies a lot: between 4-20ms. Here is an sample:


Any idea?

[DW_Microsys]

One last thing.

If I use SetSystem 3,0, then the PLC will lost communication all the time, both on RS232 port and RS485 port.

If I use Setsystem 3,1, then I notice a lot of improvement on both ports, but still got a few times communication lost.

Eventually, I fixed the RS485 ports to "No Protocol", I got good communication virtually all the time.

Here are the commands in my PLC, lastest version:

Setbaud 3,6
setbaud 1,6

Setprotocol 3,10
setprotocol 1,1

setsystem 3,1

Regards,

[support]

Thank you for your quick reply. I managed to did some more test yesterday, here are the summary.

1. The bit width: you are right, I tested in the way you described in your post, the bit width is 26us. It was the data pack width confused me. Baud rate 38400, 1 start, 8 data, 1 stop, HMI gives the following data pack (260us width)

While PLC gives the data pack of 284us:

Looks like the PLC gives 2 stop bits instead of one.

You are right that for T100MD+ PLC when set to 38,400,8,1,n the data packet size seems to stretch to 284us and when set to 38,400,8,2,n the data packet time is 315us. The same settings when sent to F-series PLC resulted in packet time of 260us for 1 stop bit and 286us for 2 stop bit.

At first it does appear like the hardware in the M-series has inserted an extra stop bit after each character is sent. However, when we changed the baud rate to 9600 bps the packet time becomes exactly 10-bit time (meaning no extra stop bit) and when we changed to higher baud rate than 38400 the packet time become more than 11-bit time. So it appears that the extra 24us of delay at 38400 is actually due to the interrupt latency time for the CPU to load the next character after the last character has been sent out of the UART. The F-series PLC UART has double-buffering so the interrupt latency would not impact the packet time. F-series 32-bit CPU also runs much faster than M-series so interrupt latency is also much shorter.

However, this extra delay would not impact the communication since the bit rate is still correct and the asynchronous communication are synchronized to the falling edge of the start bit. The only effect is that transit time of the response packet from the M-series PLC is 10% longer than expected when running at 38400 bps. The M-series PLC however should have no problem receiving the incoming data at 38400bps even if the HMI send the data with 260us packet time.

[DW_Microsys]

That what I thought.

How about the other questions, 2?

Do you have any information about how to estimate the executing time of a customer function? Yesterday I had some new problem with communication again. In one  scenario I have two more customer functions activated, and the PLC stop response to the HMI again. In these two new customer functions, no EEPROM access, no communication command, just data processing (find max, get average, set relays, etc).

[support]

We don't seem to be able to repeat what you mentioned in question 2 - when PLC is first powered up we sees that it respond to incoming message within about 4-20 ms. This is without running the SETBAUD command. We will conduct further test to verify this.

The overall execution time of the custom function should not impact the communication there are a number of places that the CPU would check for incoming host link or MODBUS commands and respond to it even within a custom function.

There isn't a quick way of determining the scan time of a single function. You can however use an output to toggle itself and use an oscilloscope to check the resulting wave form which give you an idea of the scan time of the entire ladder+BASIC program:
     Out1                   Out1
|---|/|-----------------(OUT)

[DW_Microsys]

Maybe you have a newer version of firmware? I checked question 2 with 3 PLCs and got the same result. All my PLCs have same version of firmware: T100MD+r50.

Regards,

[support]

The most current version of CPU firmware is r50 which has been in use for the last 3 years.

I ran the test again and realized that when I send a ASCII protocol such as the host link command, the M-series CPU would respond between 4 to 20ms. The same timing happens whether the SETBAUD 3,6 is executed or not.

However, after re-reading your post I realized that you were testing with MODBUS RTU command.  I then used the Modbus Poll program on a PC to perform the test and I did observe what you have reported. i.e. the CPU took about 30ms to respond to each RTU command when first powered up. I then ran a CF that executes the SETBAUD 3,6 command and the response time to RTU command is much shorter.

When another custom function that runs the SETSYSTEM 3,0 command is executed. I did find that the response time is reduced to around 5ms. However, the "Modbus Poll program was still able to maintain uninterrupted communication with the M-series PLC even if the response time is being set to shortest possible  In my test the PC is connected to the PLC via a USB to RS232 converter and an Auto485 adapter. The Modbus poll program is able to poll the PLC every 0.1s to read the holding register values using Modbus RTU command protocol.  So in our test the Modbus RTU communication via COMM3 continue to work without an issue when SETSYSTEM 3,0 is executed.

Your problem seems to have something to do with the configuration of the Maple System touch panel to talk to the PLC. You may want to try using the Modbus Poll or similar program to talk to the PLC to test whether the issue has more to do with the Maple unit.

An evaluation (time limited) Modbus Poll program can be downloaded from: http://www.modbustools.com if you wish to test the communication using a PC.

[DW_Microsys]

Did you tested with a Maple HMI, like 5056T or 520T? I have both, and both give the similar problem.

I double checked with a thrid party device to monitor the command HMI sent out. I don't see any problem. However, the PLC somehow will skip some command - no response. I don't think it is caused by the configuration of Maple HMI, I already tried every sigle combination and the problem is still the same. From the oscilloscope, I can tell the command from HMI is right; the PLC just skip.

Could you test with "set relay" command, together with pull registery? To me, the problem always happens when the HMI try to turn ON/OFF relays on PLC. I have a watchdog circuit to monitor the communication between HMI and PLC: the HMI will toggle one relay every 200ms; The PLC use the N.O. and N.C. contact of this relay to drive two timers (with 1500ms set value). I notice that the timer will time out from time to time, may happen about every 10 miniutes.

If you have a Maple HMI, I can send you the test problem I used to debug.