Thank you! My system runs well and won’t be upgraded.
Thank you! My system runs well and won’t be upgraded.
I didn’t see it mentioned, but were there any changes to the modbus scaling (bug fixes)?
Thanks Jonathan, good to know there is a better protocol on the horizon.
I’ll have to test the strategy name change dropping the tag bindings, in the past it really did wipe them out…
The port is not shown with the strategy name in the picker, so they are identical in the tag picker.
Yah and if you had, maybe I could fix this job where I have ROK kit and 2 separate PCs with Groov Server. I had to connect to each controller separately and the problem is that Groov is the more unreliable part, so it goes down, and the controllers never switch. When the first Groov goes down, then the users are looking at the second sever and it says “this controller is off-line”…pretty confusing and makes Opto look pretty bad.
Unfortunately, my first choice would have been Pac Display but the engineer wanted a browser based software.
If anyone can see a method to make the Groov server switch from one controller to another, I’m all eyes…
I didn’t specifically go in to try and fix scaling in the Modbus code, but all of the scanner code was reworked in 4.1, so it very well may have changed.
These seem to fall under this heading still. So…
I seem to missing a bunch of trend data randomly that didn’t happen before.
I am having way more tag/controller connection problems than ever before. These are constantly appearing/disappearing as I look at a single page. Sometimes they will not go away, but if I duplicate the tab (in Firefox), the newly displayed page is working fine.
Anything interesting in your logs?
Those VACUUM errors are a bit concerning: those probably mean there’s an outstanding database job that didn’t get cleaned up properly. A restart should clear those up.
The timeouts are just timeouts, and those particular ones happened while you were running R4.0. (ControlEngineTagSchemeHandler was replaced with ControlEngineScanner in 4.1)
How does your device health look? If you look in the Configure Devices dialog in Build mode, you can see which devices are actively in use at any moment along with some information about them:
And if you select a device and click Device Health, you can get more detailed information:
In the case where opening up another browser window clears up the errors, does refreshing also clear them?
Ok, so Degraded means the device isn’t keeping up with the number of requests groov is sending it, and is dropping requests to keep from overloading it. At the moment, it buffers up to 40 pending requests, and once that buffer is full it’ll drop the oldest reads from the queue, keeping any writes. We assume reads will be sent again presently, but we don’t want to lose track of writes. (Writes also jump to the beginning of the line.)
I may need to tweak that buffer length and number of tags per request (or expose them as something you can tune), but in the meantime I’d suggest bumping up your scan interval on the affected devices. It defaults to updating values once a second (that’s been the fixed scan rate in groov since its initial release) and the devices just aren’t keeping up with that. (They probably haven’t been for awhile, it’s just a lot more obvious now.)
My client wants to buy a Groov ser for win this week. Is R4.1a all right?
Yes. That is the version of groov Server for Windows that I am using.
