
Pyretta
Members-
Content Count
13 -
Joined
-
Last visited
Community Reputation
1 NeutralAbout Pyretta
-
Rank
Member
-
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?
-
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.
-
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
-
Pyretta started following Data table having random values written to it.
-
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