I just uploaded/installed 4.1a update and I have a few tags that are broken:
And when I try to go to the build page, it hangs on the “Loading Tags” notification:
I just uploaded/installed 4.1a update and I have a few tags that are broken:
And when I try to go to the build page, it hangs on the “Loading Tags” notification:
Hmmm, I am running it here on groov server for windows and a groov EPIC… I don’t see those issues…
What device are you seeing this on?
What browser are you using?
Anything in the logs?
I am using an AR1. I have tried Firefox, Chrome, Edge. All are up-to-date and result in the same problems.
groovLogs.zip (391.8 KB)
It looks like there are a handful of tags in your project that 4.1’s failing to load correctly:
2019-02-15T10:50:51-08:00 TagDbHandler.getTagById() - Exception occurred while retrieving tag with id 1701 WARN - com.opto22.groov.server.database.TagDbHandler
2019-02-15T10:50:51-08:00 TagDbHandler.getTagById() - Exception occurred while retrieving tag with id 1702 WARN - com.opto22.groov.server.database.TagDbHandler
2019-02-15T10:50:51-08:00 TagDbHandler.getTagById() - Exception occurred while retrieving tag with id 1703 WARN - com.opto22.groov.server.database.TagDbHandler
2019-02-15T10:50:51-08:00 TagDbHandler.getTagById() - Exception occurred while retrieving tag with id 1704 WARN - com.opto22.groov.server.database.TagDbHandler
Would you mind contacting Product Support and sending in your project so I can take a look at it?
I just sent an email to support.
Interesting: I just loaded the most recent project backup (today, before update) onto a demo version of the Groov Server and it is acting the same.
That’s honestly a good thing. There were some tweaks to the project database format and it looks like something changed that our automated tests didn’t catch.
If anyone else runs into this: it’s a bug parsing addresses for manually configured Opto 22 I/O Unit tags. I should have a beta w/ a fix ready Monday afternoon PST.
You got all my files? I had to send them twice.
Yup: you should have a patched up version of your project in your forum messages that will load for now. Working on a fix this morning.
Everything seems to be working with the update (b). I did not need to revert to the backup.
Glad to hear it! Sorry it happened in the first place!
What upgrades does R4.1a have over R4.0c?
Does my Groove Server for Win R4.0c also need to be upgraded?
Check out the readme notes and make your decision.
https://www.opto22.com/support/resources-tools/documents/rm-groov-server-for-windows-readme
Is that on a per-tag basis or per-device? If per-device, will groov allow us to enter the same controller twice (same IP) so we can have different tags with different scan rates? Trying to help out a poor R1 that groov is hammering.
Is that on a per-tag basis or per-device? If per-device, will groov allow us to enter the same controller twice (same IP) so we can have different tags with different scan rates? Trying to help out a poor R1 that groov is hammering.
Per-device, and no, it’ll still stop you from creating a second device with the same address + port.
So if I start an alternate host task on the controller, then I could have it setup as two devices each to a different port - then upload the tag database twice to groov, maybe?
That would probably work.
I downloaded the latest groov for Windows, and yes, it does work. Both controllers are listed with the same name (of the strategy) in the tag picker, so they could get mixed up if you’re not careful.
Unfortunately, there isn’t enough tags for me to move to the lower refresh rate to help the performance much. It’s a “table” of data that is updated based on user input in other places on the page. Most of the data doesn’t need refreshed until the user clicks a button, which triggers the strategy to update other variables that then need refreshed in groov. But the users expect a response after they click a button…so it needs to refresh quickly.
I’m not sure if this is a groov scanner issue or a PAC issue. The PAC only responds one tag per packet, which is horribly inefficient. Not sure if there is some other protocol groov could be using with the PAC that would be more efficient.
Also, this is still a problem:
Can’t rename the strategy without having to reconnect all the tags. We end up backdoor-ing this by editing the groov database instead.
Anyways, thanks for your help.
I’m not sure if this is a groov scanner issue or a PAC issue. The PAC only responds one tag per packet, which is horribly inefficient. Not sure if there is some other protocol groov could be using with the PAC that would be more efficient.
There is a more efficient protocol, I want to switch to it, but I opted to be a bit conservative in this release. I already changed a bunch of the scanner internals to get this far. The protocol I’m using right now lets me send all of the requests in one batch, but yeah, the controller dribbles the responses back.
Can’t rename the strategy without having to reconnect all the tags. We end up backdoor-ing this by editing the groov database instead.
I think that’ll work safely: all of the other tag information matches, so it shouldn’t remove anything.
Both controllers are listed with the same name (of the strategy) in the tag picker, so they could get mixed up if you’re not careful.
That’s why the at '127.0.0.1:22001' bit after the strategy name on controllers. I’m honestly not sure why we went with not allowing you to name controllers in the first place: that decision is before my time. I came on a few months after the initial release.