kewakl (Customer) asked a question.
This is the Win7 pc. Yeah, IT is that slow.😥
Around 00:03 in the attached video, the first element of a String array [RECV_RESP_HISTORY] shows out of range, the rest of the array is apparently just fine!
Another string array [ProcessLoopMSG(100)] also shows out of range at the same time.
This behavior is also visible in the ladder. -- see image
This oddity is intermittent. I am not sure if this is a PLC issue or a GUI/dataview issue. We have witnessed both.
I will try to reproduce on the Win10 pc.
According to Process Explorer, this instance has been running since 10:34:27 AM 5/24/2021
It is currently 11:58:48 AM 5/25/2021
I have made many transfers to PLC in this time.
EDIT: Firmware 1.2.7.66 Software 3.0.9.26
EDIT: Yes it happens with Win10, but with a twist.
The twist is that in the dataview, we see the two string arrays:
ProcessLoopMSG and ConfigLoopMSG.
These arrays are SOURCE MESSAGES. They are never the destination of any instruction.
Why does the editor insist on showing changing contents?
ProcessLoopMSG(100) should NEVER contain the results of the SCPI FETCH (*FETC?) query. It should be 'DIGITAL INPUT' until/unless I change the function of this process sequence step.
Something has gotten corrupted!
I do have an Error History Entry:
24MAY21 07:59:26 E04309 Prj Ldr Svc Err SRAM_Init
It took me about 10 minutes to compose this EDIT, because for some reason the simulator kept trying to do 'SOMETHING' even though I did NOT request that the simulator DO ANYTHING! Every time the simulator attempted to do 'whatever it was attempting to do,' it would STEAL FOCUS from this editor and I would have to force focus back to continue.
Eventually, I would get a message that the simulator failed to do something that I did NOT REQUEST, like START, LOAD or CONNECT -- or ANYTHING! ---SMH!
How about not letting the simulator do anything until/unless I click on the SIMULATOR button?
I do have another P3-500 to test for similar behavior. I will swap CPUs and update this post.
EDIT: replaced CPU. setup to same FW/SW. Transfer (ethernet) to CPU took about 10 seconds.
With the other CPU, I was seeing transfer times of about 90 seconds. It may be that subsequent transfers to a CPU with a running project have to be more careful than the first transfer to a blank CPU.
Original CPU P3-550+10818F043C2
Replacement P3-550+12604F143D
Please contact technical support and provide the most recent online system report so we can try to duplicate.
I have replaced the CPU. Does it matter which CPU is installed for the SysRep?
Reading over your latest updates once you replaced the CPU the transfer time was reduced however does the issues still persist with the index out of range issue?
I have not observed it.
The original CPU has been installed for about 9-10 years and I had not (until recently) observed this behavior.
It may be that in one of the recent project transfers, something happened. I have had a couple of messages about not being able to transfer the project (something about possible corrupt project) but the project transferred on the next attempt.
There was one occasion that the software forced a STOP MODE transfer when the status field at the bottom of the GUI indicated a runtime transfer.
I had just added or expanded (I don't remember which) an INT array to log a process action. After this stopmode transfer, some (not all) INT tags that are marked as retentive were reset to zero.
After I noticed and tracked the recent issues, I did restart PAC Suite and I did a power cycle on the CPU. This did not resolve the issues. I plan to remove the CPUs project and check again for these issues, but I will use the replacement CPU for the immediate future.
If you have any ideas or checks for me to make, let me know.