CPM2a program cycle times settings

I need to understand the Cycle times settings in the Omron CPM2a CPU I have a scaling/labelling system that is experiencing various communication dropouts that I am trying to troubleshoot. When I looked at the settings I noticed that the cycle times are fixed at 120 ms. I would like to be able to calculate the actual cycle times and hopefully set the CPU to one that more closely matches my application. Any advice or information would be useful. I already have the programming manual on this CPU however the explanations are somewhat daunting.

You are confusing Cycle Monitor Time with actual Cycle Time.

Cycle Monitor Time is a setpoint which triggers an a alarm when actual Cycle Time exceeds a preset amount.
Actual Cycle Time comes set as a default to variable or as fast as possible.



Phil: This is an absolute bear to accomplish. Why so hard to post a .jpg?

OK if I understand correctly the peripheral port servicing time executes after the I/O refresh. ON my application as I have no alarms with settings set at monitor cycle time fixed 120 ms, cycle time at variable. servicing time not selected on peripheral port or rs 232. Can I speed up the host port servicing time by setting the minumum cycle time as low as possible and setting the watchdog a little above that value? or would leaving the cycle as variable provide optimum performance on the RS 232 host port?. My application has the link between the Host port to the PC no protocal. default 9600 1,7,2,e no cts. I wish to upgrade those settings to 19200. and upgrade the time the program monitors this port. In order to help compenstae for slow responses from our database server

If you have the cycle time set to variable (see above) the PLC is operating as fast as a possible. If you set it to 1 ms and the PLC program takes longer to execute, it will increase cycle time to accomodate. There is no advantage to setting a lower cycle time than the program actually takes to execute.

Since your port is set to no protocol, obviously you are using TXD and RXD in the programs. Therefore you are cheating yourself by decreasing the time for execution program since the TXD and RXD are program instructions. Increasing the peripheral service will only assist if you are using Hostlink or NT-Link protocols which are serviced after program execution.

Increasing the baud rate for the port will help get your string out of the port faster, but it will not decrease the overhead it takes to get the command and the response calculated. You would think you could double the total overall throughput by doubling the baud rate, but in true applications expect about a 20% increase in throughput.

Why does your application not use Hostlink protocol? Please explain the nature of the string conversation between PLC and host device.

I have 5 TX(48) strings that get sent only upon error events ie jam modes.
then I recieve one Rx(47) event that signals when the labelling application is completed or a jam has been cleared by the operator. the numbers are usually a numeric value as an example numbers like 31 32 etc. The problems I have isn't on the transmits but rather on the receive event this is due to slow access on our database files on our server which connects via the Noax touchscreen to the servers with a fibre optic connection 10 base t. The actual developer of the PLC program wasn't that familiar with the protocals so decided to keep everything at the default unless problems occurred. Unfortunately he is no longer with us. The suport team is currently working on our databasing slowdowns I wanted to ensure that the PLC is set up for as close to optimum as possible. Jay I could probably send you a copy of the various program sections however be advised that all the tags and descriptors are written in french.

Unless you are using timers in the handling of your RXD sequences, you have probably done everything possible to insure that the PLC is not the bottleneck. As a database grows larger and larger the turnaround time becomes an issue. Have you thought about limiting the database transactions to a set acturial based window, (maybe, thirty days) and move completed tranasctions to a long-term database. Having just been through a similar scenario with a database, this was the answer for us.

What we are looking at now is increasing our communications to 100 base t from the touchscreen to server. The other alternative we are looking at is having the daily transactions stored on a temporary daily database on the touchscreens themselves then passing communications simply for updates.