Anyone else seen this error before? I have a started a ticket with support already.
When I hit abort, the PAC controller has it’s memory totally cleared. Strategy & Persistent data gone. When I hit ignore, it keeps on moving, strategy keeps running and persistent data is fine. Next time this happens I will do ignore and then restart the PR1 to see if everything is still there.
I will update this when I have some answers from support.
Did you notice any problems besides this showing in PAC Control. For example, if you just let it run did things seem to keep working? I’m on a time sensitive project but I can’t send this out if it is going to ‘die’ on us.
Unfortunately I was in a pretty fluid situation with it and could not look at the logs on the PR1.
I saw the error in PAC Control like you, so I was not sure what the long term effects of it will be if you are not in debug mode.
@Beno I was running a very basic project. But it did have my ‘local’ controller as a device. I was using node-red to poll a modbus slave and insert the data into a pac table. I was polling 11 devices and inserting data into 20 tables based on floats or integers. I was also subscribed to a MQTT server and inserting ‘relevant’ data.
At first I thought I was just sending to much data every 5 seconds, but I put an RBE block on it, and slowed down the writes considerably, but still the problem happened randomly.
The extra info might be extraneous, or it might help form a bigger picture.
It helps. I came across this independently here, and it looks like an issue with how groov View is reading numeric tables. Do you have your groov View project displaying the values in those tables?
Yes I do read from numeric tables. How about writing to numeric tables?
My temporary workaround would be to create a bunch of float/integer variables and read/write them that way. Have PAC ‘translate’ those to/from tables so I don’t have totally change the way things work.
I use tables to cut down on the amount of reads/writes in Node-Red
Engineering found the cause of the issue is related to using Groov View to read numeric table values from either a GRV-EPIC-PR1 or PAC controller. This affects Groov View R4.1a and R4.1b and PR1 firmware 1.3.0
If not in Pac Control debug, are there any issues to allowing this to keep running? Or am I going to need to downgrade firmware to meet my project deadlines.
I don’t think so, but Ben might know better. For me, I didn’t even have PAC Control running, just talking to an R1, and it recovers pretty much instantly. I see a blip of yellow triangles in groov View at regular intervals, but everything keeps working.
I do see the blip every once in a while, that I can live with. But when in Pac Control, if you hit abort, it clears the memory including persistent data.
If you’re running into this, please contact Product Support. There are betas available for groov Server for Windows, GROOV-AT1, GROOV-AR1, and GRV-EPIC-PR1 that address it.
So far everything is working fine. I haven’t gotten any more messages in PAC Control. I will keep it going and let you know if there is any changes to this.
I found an issue and what I had to do to resolve it. Not sure if this is related or not.
When reading from a numeric table and you read from an index greater than what is in the table, it stops communicating with the PAC controller. For example my table tank_levels had a table length of 10, but I was reading the 11th index. Since it was not there the problem happened.
In PAC the error table shows -12, invalid table index. Once I made the table bigger and uploaded and refreshed the groov page, it was all working again.
I understand why this would throw an error, but I think it could be handled more gracefully with warnings about the table being to small or something like, not just that it can’t communicate with the controller.