I am posting this in the FactoryPMI since this the only place I see this problem.
I have an Omron CS1 PLC, Kepware OPC Server and your software.
I have several values in Kepware defined as Long BCD. I can browse without errors
These items are in FSQL groups as Int8 and write to SQL without errors.
These same items are added as SQL tags and in FactoryPMI I get a quality error of [quote]OPC_CONFIG_ERROR[/quote]Any item that is defined as Int8 has this error. Also, if I edit these tags within FPMI’s SQLTags browser and change the datatype to Int4, it starts working. Note: currently the values in these tags are low and only occupy one word.
From what I can gather from the Kepware documentation, “LBCD” is defined as a “Four byte packed BCD”, so Int4 would be appropriate. I’m not sure why the FactorySQL groups will work with them configured as Int8 and the SQLTags won’t, but setting running them as int4 should be fine.
First off, I need to correct my previous claim. At FSQL the group tags are in fact Int4. The SQLTag definitions were the only tags defined as Int8. I did change them all to Int4 and all is well.
Another question.
As I have been converting each machine over to use this software I have been taking ALL OPC tags and dragging them to an FSQL tag group, about 1000 per machine. Currently I am using only about 5% to 10% of these on actual screens. I am making the assumption that these tags are only read/updated when the screen is shown or a call is made from a function. Is this an incorrect assumption? Am I increasing the task load for items I may never use?
No, actually all tags are updated according to their scan class, so by default every 5 seconds. The only way to link between the screen and tag execution is to create a leased scan class, which will execute whenever one of its tags is on the screen.
Your question wasn’t exactly clear: are you bringing them into a FactorySQL group, or as SQLTags? If it’s a group, you probably should just delete the tags you don’t need. For SQLTags, you can keep them, but I’d recommend setting their “enabled” property to false, and then just enable them as you need them.
Sorry for the confusion.
All OPC tags are brought in as SQLTags.
Only select OPC tags are in a FactorySQL group.
I was experimenting with selecting multiple SQLTags and disabling them. If I do this and accidentally disable a tag that is used in a script or on some obscure screen I forgot to look at, what will happen? Is there a way to query these tags to find out wich ones are not being used? I guess I should have asked this question before now.
Unfortunately there isn’t really a way to find out precisely which tags are in use. This is asked for from time to time, so maybe someday soon we’ll put something in. However, in the mean time, if you accidentally disabled at tag that was used on the screen, you would just get an overlay on that component that showed its source tag was disable. In a script you’ll probably get an error.
Well, I don’t think having all of the tags in a leased scan class wouldn’t really get you very much, due to how leased scan classes work. When a window is opened, it looks at all of the tags used in it, and gathers up the scan classes they belong to. Those scan classes are then leased, and all tags contained in them (including any not on the window) would be executed at the faster rate.
[Note: Since this is a common misconception about leased scan classes, I should note that in the future we will likely make them work more like one would expect: on a tag by tag basis]
As for how it would affect scripting- disabled tags are going to have overlays and throw errors, but tags in leased scan classes won’t do anything unusual. Even if the scan class is not currently leased, it is running, at the slower rate (which could be 0, not at all). So to the system, everything’s normal.
I guess another alternative to disabling tags would be to have a slow scan class for tags that you think you aren’t using, and then move them to a faster one as you start to use them. Honestly though, I think disabling them is better, because with this method you run the risk of having tags on the screen that rarely get updated and not knowing it. Another big reason I suggested disabling them is because then they won’t even get loaded when the system starts - saving some startup time.
So let me see if I get this right because it might also be something that is affecting my project as well.
If you have 500 SQL tags, (100 alarm, 100 config, 100 system counts, 100 system, and 100 settings) It is better and more efficient to place them each on their own scan class rather than having all under the same scan class. In this configuration the system counts and system are required to be the fastest updates where as the others can be more slower. If I place them all in the same scan class, say at 1000mS, it could cause stale state and slow update issues because the system is trying to do all 500 every second.
So would it be safe to say that if you set up 5 scan classes, 2 at 1000mS, 1 at 3000mS and the remaining 2 at 5000mS it would run more efficient because it would not be trying to scan all 500 at one shot?
Now on the event of the two 1000mS scan classes, Would the system first take the one scan class and execute it for one second then it would execute the second one the next second or how would that work?
So if I understand what is being said here you can enable and disable a SQL tag using scripting?
Is it possible, since leased scan class only executes when one of its tags is on the screen to also have it only enable the tags that are used? Or is this the case by default? Just so I can attempt to be clear here say you have 75 SQL tags and they are under the same leased scan class but on the screen you only have 30 of them displayed, does it still poll all 75 or just the 30 that are used?
[quote=“Colby.Clegg”]Hi,
No, actually all tags are updated according to their scan class, so by default every 5 seconds. The only way to link between the screen and tag execution is to create a leased scan class, which will execute whenever one of its tags is on the screen.
Your question wasn’t exactly clear: are you bringing them into a FactorySQL group, or as SQLTags? If it’s a group, you probably should just delete the tags you don’t need. For SQLTags, you can keep them, but I’d recommend setting their “enabled” property to false, and then just enable them as you need them.