FTV SE 11 Derived tag expression won't stop running? idea?

[coryjs]

I asked this question briefly in my previous post long post, I'm asking again here as the main point so it doesn't get buried. I am pretty new at this so I am expecting to have overlooked something simple.

I have a factory talk SE distributed network server and was learning how to use derived tags to have the server communicate to a PLC. I right clicked the component and clicked start. The expression worked fine, it's running right now turning a bit off and on PLC side.

Next, I right clicked the component again and clicked stop. It never stopped.
I tried running DerivedOff on the component. I tried deleting the component and restarting the SE server. Restarting the SE server stopped the expression until it was rebooted.

Anyone have an idea for me?

 

[Operaghost]

What is the Diagnostic window showing you? Is there an error message when you try to stop? You should see two messages letting you know it is starting. The derivedon command, and then a system response letting you know it is starting that derived tag file. And then another two similar messages letting you know when it is stopping.

The derived on command will start running that derived tag file and it will keep running until it receives the derivedoff command. If the HMI server loses power then the derivedoff command was never sent. When that HMI reboots, the derived tag file will not automatically restart itself (unless it was configured to run automatically at power up).

Now as to why your bit is still flipping after issuing the derivedoff, here is what might be happening. Lets just say for a moment that I told you that when I send you a "1", I want you to start flipping another bit on and off. In this case, I am sending you the trigger to start flipping the bit, but you are the one actually causing the bit to flip on and off. Now imagine that after I told you to start, that I just disappeared. I never sent you a "0" to tell you to stop flipping your bit. Your bit would keep flipping since it was never told to stop. So I (the HMI) just trigger whether the bit should be flipping or not. You (the PLC) are the one actually making the bit flip.

Now a different take...Let's say now that I am the one flipping your bit. I send a "1" and I send you a "0" directly to your bit. If I disappeared, then your bit would be stuck in it's last state.

An issue that catches people frequently with derived tags is that they do not zero out their values when you stop executing the file. They retain their values. So you need to make sure you have a way of resetting that value.

Is it possible to post the screen from your derived tags file so we can see the expression(s)? I suspect we might need to incorporate what they call Events to make this work the way you need.

Likewise, are you able to verify who is flipping the bit? Is there logic in the PLC that is getting triggered by the HMI, or is the HMI directly flipping the bit. By your description it sounds like the PLC is doing it. Which I think most would find preferable.

OG

 

[coryjs]

Against my better judgement I deleted the derived tag file before this post. I still have the expression partly because it's simple and partly because it's the solution Rockwell sent me in TechConnect QA47324.

Expression: If Heartbeat > 0 Then 0 Else 1.
So, not preferably, the HMI is directly flipping the bit.

The first time I would use DerivedOff there is no error. When I attempted to use DerivedOff twice or more it would say "Derived Tag file 'XXXX Derived Tags' not running. Even so, I could still see the bit turning off and on in the PLC. Diagnostics viewer is showing my history during this time and it's just me trying to turn it on and off a bunch while getting that error and nothing else really informative.

I'm not sure if I should recreate the file and derived tag with the same names and try it again, or if that would make it worse.

I am happy to learn doing this as an Event, but first I need to learn how to stop this rogue expression I messed up.

I have attached what I am seeing in my diagnostics viewer, restating that the derived tag would keep running the entire time.

Thank you for the excellent information.

 

[Operaghost]

So that diagnostic information is straight-forward. The error at the end is normal if you try to stop something that isn't running.

I see the Rockwell Tech Note that describes what they are having you do. There really isn't "bit flipping" going on here. They are simply writing a value to a timer accumulator to force it to restart. They are writing a 1 or a 0 to the timer accumulated value.

There are two parts to their solution. The first part is to write logic in the PLC to start a timer. The second part is to create a derived tag in FT View.

I could not make their example work using derived tags the way they wrote it up. Now, I am using an emulator and not a real PLC. But the derived tag for me might reset once, but it would not reset a second time so it just kept faulting out on me. But, with a small change I got it working. I changed the expression to the following:

If Heartbeat > 1000 Then 0 Else 1

I set my timer up to count to 10 seconds. You might choose to set yours longer. So now if the timer is less than 1000 it can time. If it is greater than 1000 it will reset. You might be able to get by with a number less than 1000. But greater than zero did not work for me.

However, once I stopped the derived tag file, everything did stop. However, the result of that was if the timer hadn't already generated my fault, it would do so in sort order since the timer would continue to time. But I do not see any bit that would be "flipping". Can you show us a screenshot of that part of the logic? I've included screenshots of what I did.

OG