LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get DSC Warning 70 parameter off-scan when On Scan status bit is ON

I am reading and writing to an Opto 22 panel through DSC and OPC servers. Initially, I place (global) tags on-scan and then take unused tags off-scan individually. No errors or warnings are generated when the program initializes and runs at atartup. When I change tag mapping in my program, I again place tags on-scan and turn off unused tags individually. It is the same vi used for initialization and for re-initialization. However, after the second on/off scan operation, I get a "Warning; ; 70; GW508Optomux.DI4.16; Engine; Tag is off-scan" when I try to read the tag. This occurs for for all tags that were not initially on but were turned on during the second operation. When checked independently, the On Scan bit is "ON' for that tag as it should be. In fact all the tags are either turned on or off appropriately. I have installed 1.5 sec waits but this does not solve the problem (scan period is 1 sec).
T-Ray
0 Kudos
Message 1 of 13
(7,122 Views)
Hello,

I am going to try to reproduce what you are saying but got some questions. What version of DSC do you have? How fast are you turning on and off the tag? Is it always on the second on and off?
Thank you

Ricardo
0 Kudos
Message 2 of 13
(7,111 Views)
I am using Version 7.1 of Labview and DSC (purchased in Dec. 04). I am not cycling tags on and off routinely just when there is a setup change. So speed is not an issue. I have over a 1000 predefined tags between Modbus and Opto 22. Our customers naturally will not use or need all of these. My hope was to turn off all unused tags and only turn on the ones that are being used. This works when the program loads and initializes but does not work if the user changes the setup. Exactly the same routines are used for the initialization and for the reinitialization.

I have tried various sequences from turning tags off globally then turning on only the ones being used to turning them on and off individually by sending an array of the on tags to the SET Tag Attribute.VI followed by a complementary array of off tags. Reversing the order does not solve the problem. I have added several seconds of time delay between the on and off commands and after the last command. Nothing seems to fix the problem.

All data transfers to the tag engine are via the Read Tag.VI and Write Tag VI. Data sockets are not being used. Error codes are sent through the Get Tag Status Info.VI.

I get the off-scan warning only for tags that were not turned on during the initial startup. If I read the scan status independently for the failing tag, it is on. This is a contradiction and suggests a DSC bug to me.
T-Ray
0 Kudos
Message 3 of 13
(7,110 Views)
Hello T-Ray,

Thank you for the update. I tried to do something similar myself with a modbus and I have no problems. What do you mean by initialization? I created two tags, and through the set attributes VI I put i on scan and off scan. I then started the tag engine and the ones that were not on scan did work later after putting them on scan.
Is this what you are doing?
Thank you


Ricardo
0 Kudos
Message 4 of 13
(7,097 Views)
Thanks for the response.

Power on initialization consists of starting the tag engine followed by reading the tags so I can configure my arrays to match the Opto 22 hardware installed, followed by the Tag On routine which turns off [all] tags and then turns on the tags being used. This routine builds a one-dimensional array of tags and then uses the Set Tag Attribute VI with SCAN ON (ring constant) and 1 for the value. This routine is then followed by a routine that sets the scaling for analog values. This uses the Set Multiple Attribute VI as it sets both raw and engineering scaling. Scaling is followed by a routine that reads all the digital inputs and stores the current value for latter testing if changes occurred. This is the extent of the primary initialization.

When the user changes the setup, the system performs the tag off/on routine, the scaling routine and reads all the digital inputs as before. The same 3 routines are used in both cases. User setup changes consist of enabling or disabling outputs (in my software), changing Opto 22 physical addresses, or changing a parameter between Modbus or Opto. I do not stop and restart the tag engine nor is it necessary to reread the physical configuration of the Opto panel.

Since I had Modbus up and running before installing the DSC package, I have not tried to retest that part of the system. My software runs as a Modbus slave. I do not currently have a Modbus master linked to the testing computer. However, I have not enabled any Modbus I/O either. I am just trying to get the Opto 22 part of the ystem working at this time.
T-Ray
0 Kudos
Message 5 of 13
(7,076 Views)
Hello,

The reason I used a Modbus is because I don't have the PLC that you have. But it should work the same way.
Can you do a simple test in a new VI where you turn on and off the scan of only one tag and try to read from it?
So in your VI you should only have the Set Attribute and the Read Tag. You can enclose these VIs in a while loop. Let me know if you get the same errors.
Thank you


Ricardo S.
National Instruments
0 Kudos
Message 6 of 13
(7,072 Views)
OK, I created a Tag list consisting of 2 digital input (boolean) Opto tags. For both tags in the "operations" section of the tag configuration editor, the "Update Engine Database" is checked "Always"

I then created a new program that did the following:
Outer Sequence: Frame 0: Start Tag engine
Outer Sequence: Frame 1: Do While loop with Inner Sequence
Inner Seguence: Frame 0: Turn off [all] tags; Frame 1: Turn on Tag #1 [SCAN ON]; Frame 2: Wait 1500 ms; Frame 3: GET SCAN ON attribute for Tag #1; Frame 4: READ Tag value for Tag #1 and decode error using STATUS
Outer Sequence: Frame 2: STOP Tag Engine.

Test results:
Tag #1 status is returned as ON, Tag value and "no error" is returned correctly on first loop pass. On second and subsequent passes, Tag #1 status is ON but tag "off-scan" error 70 is returned. If the input value is changed (physically switch the hardware state), a "no error" message is again returned on only the first read and "off-scan" is returned on subsequent reads. The tag status was always returned as ON.

If [all] tags are turned on in Inner Frame 0, no errors are returned. Tag Value follows input correctly.

Increasing the wait in Inner Frame 2 to 3000 ms does not change the behavior.
Adding a time out of 1.5s to the READ in Inner Frame 4 does not change the behavior.

Moving the [all] Tags OFF and Tag #1 ON frames to the outer sequence appears to make everything work properly even without the time delays. (This actually is closer to what I am actually doing in my program, so the results are even more confusing.)

I can e-mail you the routine if you would like.
T-Ray
0 Kudos
Message 7 of 13
(7,060 Views)
Hello T-Ray,

Thank you for the update. I have done the VI using your steps but I still was not able to reproduce your error. I always get no error in the message of the status. I wired all the errors and still nothing. I have the same version of LabVIEW 7.1. Probably it is a bad install. I am attaching my VI so you can take a look at it. I don't know if it would be possible to run this same test in another computer. Now, I am still using the Modbus as the test because that is the only hardware I have available to test.
Please let me know whatever you find. Thank you.


Ricardo S.
National Instruments
0 Kudos
Message 8 of 13
(7,048 Views)
Ricardo,

I think I have figured it out. I modified your program and have attached it. The problem is not an error but a warning so it does not show up unless you decode the error messages using the STATUS VI. On initialization, the READ VI gets the correct result without error because an initial input value is specified. It does correctly throw a Warning 50 to that effect. On subsequent reads there is no warning if the SCAN ON has not been reset. So at this point, the system behaves as expected. When the tag is taken off scan, you get the warning 70 "off-scan" which is correct. However, when placed back on scan, you continue to get the "off-scan" warning until the tag input value is changed. Then on all subsequent reads, no warning is generated and the tag is read correctly.

The behavior is not what I would have expected. When a tag is placed on scan, it should read the tag properly the first time without generating a warning or requiring a physical change in the tag state. Under this scenario, how does one distinguish between a truly off scan tag and on that is merely waiting for a state change?

Terry
T-Ray
Message 9 of 13
(7,031 Views)
Hello T-Ray,

I really appreciate the VI you sent me. I was able to reproduce what you are saying and able to understand what is going on. It is actually an expected behavior for how DSC works right now. What it is doing is that it doesn't read the value once it goes on scan because DSC works with events and for it, the value hasn't changed since the OPC doesn't send that event. We will work to have something as what you mentioned, that even if there no value change according to DSC, that it polls from the OPC server at least once when goes back online. Thank you.


Ricardo S.
National Instruments
Message 10 of 13
(7,010 Views)