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 n

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 wh