Pyretta Posted November 18, 2020 Report Share Posted November 18, 2020 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 comment Share on other sites More sharing options...
MVP 2023 Ausman Posted November 18, 2020 MVP 2023 Report Share Posted November 18, 2020 How are the two units linked? Ethernet or 485? Could you use UniCan instead? It can get around all sorts of issues, and is fairly easy to implement. cheers, Aus Link to comment Share on other sites More sharing options...
Pyretta Posted November 18, 2020 Author Report Share Posted November 18, 2020 They are connected via ethernet Link to comment Share on other sites More sharing options...
MVP 2023 Flex727 Posted November 18, 2020 MVP 2023 Report Share Posted November 18, 2020 You might consider posting your programs here for us to see if there are any problems. Link to comment Share on other sites More sharing options...
Pyretta Posted November 18, 2020 Author Report Share Posted November 18, 2020 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 comment Share on other sites More sharing options...
MVP 2023 Joe Tauser Posted November 18, 2020 MVP 2023 Report Share Posted November 18, 2020 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 comment Share on other sites More sharing options...
Pyretta Posted November 18, 2020 Author Report Share Posted November 18, 2020 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 comment Share on other sites More sharing options...
MVP 2023 Flex727 Posted November 19, 2020 MVP 2023 Report Share Posted November 19, 2020 1 hour ago, Pyretta said: I only transfer data between the units using the row 0 currently. Rows 1-10 are not used at this time. This makes me wonder why you're using a Data Table at all. Link to comment Share on other sites More sharing options...
Isakovic Posted November 19, 2020 Report Share Posted November 19, 2020 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 comment Share on other sites More sharing options...
Pyretta Posted November 19, 2020 Author Report Share Posted November 19, 2020 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 comment Share on other sites More sharing options...
MVP 2023 Joe Tauser Posted November 19, 2020 MVP 2023 Report Share Posted November 19, 2020 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 comment Share on other sites More sharing options...
MVP 2023 Ausman Posted November 19, 2020 MVP 2023 Report Share Posted November 19, 2020 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 comment Share on other sites More sharing options...
Pyretta Posted November 20, 2020 Author Report Share Posted November 20, 2020 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 comment Share on other sites More sharing options...
Pyretta Posted November 20, 2020 Author Report Share Posted November 20, 2020 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 comment Share on other sites More sharing options...
MVP 2023 Flex727 Posted November 20, 2020 MVP 2023 Report Share Posted November 20, 2020 50 minutes ago, Pyretta said: 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 Out of space? Link to comment Share on other sites More sharing options...
Pyretta Posted November 20, 2020 Author Report Share Posted November 20, 2020 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. Link to comment Share on other sites More sharing options...
Isakovic Posted November 21, 2020 Report Share Posted November 21, 2020 What is the scan time on such a large program? Link to comment Share on other sites More sharing options...
MVP 2023 Flex727 Posted November 21, 2020 MVP 2023 Report Share Posted November 21, 2020 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 comment Share on other sites More sharing options...
Pyretta Posted November 21, 2020 Author Report Share Posted November 21, 2020 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 comment Share on other sites More sharing options...
Pyretta Posted November 23, 2020 Author Report Share Posted November 23, 2020 The scan time is 13 mSec 1 Link to comment Share on other sites More sharing options...
MVP 2023 Flex727 Posted November 23, 2020 MVP 2023 Report Share Posted November 23, 2020 2 hours ago, Pyretta said: The scan time is 13 mSec That's much better than I thought it would be based on your description. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now