Pyretta

Yes it was. It is also started with run as admin rights as well as my account being an administrator account.

I am using Arial 14 bold in English. The font is installed there. If I create the display not using the string library with the Arial 14 bold, the remote monitor does not crash.

I have this problem with certain displays. I am running the program administratively. I will only get this error if I put the system on a display that calls from the string library. If I rebuild this display so that I am not using the string library, the issue goes away. It only happens on displays that have a reference to the library. It is a very simple display with a text box and 2 buttons. Is this a bug?

The scan time is 13 mSec

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.

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.

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.

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.

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.

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.

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

They are connected via ethernet

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?