Jump to content

Recommended Posts

Hello,

I have a program that uses 2 V430 to pass data and commands to each other. We will call them Unit A and Unit B.

Unit A will do a MODBUS data table read on Unit B. It reads 50 bytes from address 0 on Unit B and writes them to address 0 on Unit A. After this has completed, I set a write bit and then it performs the data table write

Unit A will do a MODBUS data table write from address 600 on Unit A and write it to Address 600 on Unit B. about 50 bytes. Once the write is complete, it sets the read bit and then the cycle repeats endlessly.

This process happens all the while the unit is powered up and the PLC is not in stop mode.

When my process runs, I will set bits and values and write them to the data table that is being sent to unit B signaling it to start. The process seems to work most of the time. However, from time to time, I will see the data table that is being written to unit B will have garbage data randomly popping up and being tossed all around the table. If I disable the MODBUS read/write section, the data table stops the erratic behavior. Once enabled again, the erratic behavior continues. 

If I power cycle the unit, the issue seems to go away. 

Lets say my function in progress bit for this particular MODBUS is bit 1. If I am writing from unit A to unit B and while the MODBUS function is taking place, a write to that data table takes place. Will that cause this behavior? 

I have tried slowing down the sends and receives but that does not seem to help. 

When this has an the issue present, the read table does not seem to read properly either. My status returns from the function are 0. 

Thoughts?

Link to post
Share on other sites

Unfortunately I am not able to do that. I was just wondering if there were any limitations on writing to a data table that was in the middle of a MODBUS transfer of the same table or if there were limitations on how fast/often you are doing your modbus write/reads  I would think that if this were a major issue, I would see this on a consistent basis however, this happens sporadically  

Link to post
Share on other sites

There are no limitations on Data Table reads and writes - they are executed when they are called in the ladder code.  If you have a lot of them then the scan time may be affected a bit, but it doesn't seem like this is the problem.

It also sounds like you are hammering your Modbus transfers as fast as possible, which is where I would suspect the garbled data is coming from.  There's supposed to be a checksum in the Modbus frame but you may be stomping on yourself.  

Have you tried inserting a time delay between Modbus operations?  Will your process tolerate a 1/2 sec delay between transfers?

Joe T. 

Link to post
Share on other sites

That was my first attempt while the issue was present. I added a 5 second delay between reading and writing. It just slowed down the garbled data. 

When I put in the 5 second delay, lets say column 5 is supposed to have the data with a value of 4444. Watching the garbled data, that 4444 would shift over a few columns. 

I have seen this happen before in the first generation of the software(I am on gen 3 now) before being re-written from scratch.

To try and stop it from happening, I would set a BIT as well as a specific integer validation code that the 2nd software program would need to verify that the bit is set and the validation code is correct before enacting. But this is really a band aid  and I end up using 2 columns 1 for bit and 1 for validation code so my 32 columns is cut down to 16.

The specifics of the table for 32 columns and 11 rows. I only transfer data between the units using the row 0 currently. Rows 1-10 are not used at this time.  The garbage data will overflow into row 1 from row 0 when this happens. I have also shortened up the MODBUS length to just 4 bytes and the issue would just show up in those first 2 columns.

 

 

Link to post
Share on other sites

Maybe try using an auxiliary data table as a buffer for reading/writing  instead of modbusing directly tables PLC uses for logic. That way you can verify if data is valid, if not repeat synchonization. This may slow down your process if mistakes are frequent.

Link to post
Share on other sites
17 hours ago, Flex727 said:

This makes me wonder why you're using a Data Table at all.

My thought was that Unit A could be connected with up to 10 other units. Unit A would designate row 0 to Unit B, row 1 to C, and so on. That way, Unit A had a table of what was sent to which unit.

Link to post
Share on other sites
20 hours ago, Pyretta said:

The garbage data will overflow into row 1 from row 0 when this happens.

There's nothing in the Help on the DT Raw block, but it implies that the Data Tables are a contiguous chunk of memory.  What you're describing kind of sounds like writing a 32 bit word to a 16 bit variable.

Since you can't post your code, it's very difficult to troubleshoot the problem from descriptions only.  There is probably something in your Modbus blocks that you mistyped or are overlooking.

I suggest you contact Unitronics official support at support@unitronics.com.  They will ask for your program, and hopefully you can send it to them.

Joe T.

Link to post
Share on other sites

All the other suggestions etc are perfectly valid, but back to my first answer and my ask about the connection type.  How far apart are all the units?  UniCan is still pretty fast up to 500m.  With the troubles you are describing I still reckon you would be much better off doing everything by UniCan if your physical positioning is suitable.  The bonus is that it is very easy to add in other units as well, which seems to be a future thing in your needs.

I really do suggest that you have a good read of all that UniCan can do, in the Help files.

cheers, Aus

Link to post
Share on other sites
16 hours ago, Joe Tauser said:

What you're describing kind of sounds like writing a 32 bit word to a 16 bit variable.

Joe T.

This is exactly what I was thinking and how it behaves. 

I re-wrote the modbus communications yesterday so that it flowed smoother and had success. Unfortunately, this happens sporadically so I will have to keep an eye on it.

Link to post
Share on other sites
15 hours ago, Ausman said:

How far apart are all the units?  UniCan is still pretty fast up to 500m. 

cheers, Aus

The units are connected with about 8-10 feet of CAT5. So they are pretty close.  Once other units are tied into the system, I would guess it would add another 10 feet for each but we are quite a bit away from that stage of development and will probably be off the V430 into the UniStream series either the 7" or 10.4" since we are just about out of space on Unit A. 

Link to post
Share on other sites
1 hour ago, Flex727 said:

Out of space?

We have quite a few images around 270. Some of them are larger. I had to remove some programming for future use because every time I would load the program it would have to re-write the DLU and send the images again. The load times were in the 30-45 minute range each time I would make a small change.  Some screens are pretty elaborate and have lots of variables. I try and make it so that the variables are re-used on the displays but there are quite a few displays. 241 subroutines and 127 displays.

UnitA.JPG

Link to post
Share on other sites
13 hours ago, Isakovic said:

What is the scan time on such a large program?

We must know this! :)

Also, I can't imagine the work involved in migrating this over to UniStream. Some of your issues will be solved, but you will definitely be looking like Isakovic's profile picture before you're through.

Link to post
Share on other sites
1 hour ago, Flex727 said:

We must know this! :)

Also, I can't imagine the work involved in migrating this over to UniStream. Some of your issues will be solved, but you will definitely be looking like Isakovic's profile picture before you're through.

When I get back to the shop i'll let ya know. It will be a pain but with each generation I learn more and more about the application.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...