CLX Emulate 5000 Simulation of I/O

I've developed a fairly complex Batching PLC program using an CLX 5000 L61 PLC interfaced to Wonderware 9.5. I converted the CLX program to use the RSLogix 5000 Emulator and modified the WW app to point to RSLinx OPC instead of the DAS Server. No problems and it works quite well for manually manipulating the process (writing I/O and toggling bits). I want to take it to the next step and create a Simulation package to where the customer can actively interract with the Wonderware HMI and the Logix 5000 Emulator to actually run simul-batches.

I created a routine in the CLX (called simulate) that (I was hoping) modelled the process. As a basic example, a rung of logic would monitor the motor starter (Output) and turn on the Motor Aux (Input) which would prevent the normal run aux fault from occurring and simulate that the motor came on. I also have a lot of logic simulating analog values fluctuating (rising tank levels, varying temperatures to PID loops, etc.).

Now the problem. All tags are aliased to real I/O in the rack and via ethernet flex I/O. I didn't use the Sim32 I/O in the emulator (really saw no need). To manually manipulate the process all I had to do was use tag monitor and write (not force) a value into the tag aliased to the I/O point and all worked well. Even with analog, I could write a value of say 50% to a tag aliased to an analog input module, and the 50% value would stick. Same for thermocouple inputs, etc. For discrete, I could simply write a 1, or 0 and it would stick (again, no forcing).

However, the same functionality doesn't appear to hold true when doing it through logic. If I try to write a '1' to an Input tag, it toggles between 0 and 1 (length of scan time I imagine). I have a decrementing CPT function to simulate a tank running out with the following logic:

--[tank mode auto]----[level >= 0]-----[CPT level = level - 5]--

That works until the level hits zero and then poof, it jumps back to the initial value I had stuck in the tag through tag monitor and the above logic of course cycles again. So, to summarize, if I go to tag monitor and write a value of 50% into level, it stays at 50%. But if I turn [tank mode auto] on above, it decrements to 0 and then pops back to 50. If I write a value of 20% in tag monitor it does the same but pops back to 20.

For discretes, I have as an example:

----[motor]------------[motor aux]----

If I turn [motor] on, [motor aux] flashes on/off. If I write on to motor aux it turns on and stays on, until [motor] turns off to which it goes back to flashing off/on.

So, is there any way to do the type of full simulation I want using the RSLogix emulator (I know I could turn off the OPC and do it all in ww script, but I'd like to use the logic I have)? My only thought is to de-alias everything, but I'm confused as to why a write in monitor works, but a write through logic does not. I was hoping to keep one program and activate/deactivate simulation mode via an engineering bit from WW. If I have to dealias then I end up with two programs to maintain.


Update: I found that if I Inhibit the module aliased to the tag it prevents the above behavior. So, as a work around, can I use the simuation enable tag to dynamically inhibit I/O modules and if so, any danger to moving in/out of inhibit? I see that there is an SSV means to inhibit modules.

What you did is similar to the RSTestStand application.

In order to use the said application, part of the setup is to inhibit the IO. This prevents the behavior that you were describing. You are going about the properly. You can do it via a SSV. I'd place that rung into your simulation routine so that you don't have to do it every time. Just be sure to un-inhibit them when you are ready to install it on the real controller.

Let me start by saying I have not used Emulator, but it is on my list of things to try. I do simulate most of the new processes we install prior to start up. In the configuration of every device I add a simulate option that disables the I/O and simulates it. I add a rung to enable the simulate bits for each of the devices involved while I do testing. The analog is also simulated in the same manner. The simulation is normally used for the first round of training before start up. After the training I disable the simulation function. I don't use tags that are directly aliased to I/O, so this works well for me.

I just saw your update, and I don't see why that wouldn't work. Are you planning to use this for training purposes?

Oakley said:

What you did is similar to the RSTestStand application.

In order to use the said application, part of the setup is to inhibit the IO. This prevents the behavior that you were describing. You are going about the properly. You can do it via a SSV. I'd place that rung into your simulation routine so that you don't have to do it every time. Just be sure to un-inhibit them when you are ready to install it on the real controller.

Click to expand...

Thanks....After manually inhibiting all the I/O, it's working like a champ. It's even uncovered a couple of typos, so well worth the effort. Since my goal was just to have one program that I could move into and outof simulate 'mode', I'm thinking of forgoing the auto SSV of the inhibit and have that documented as a step into how to 'convert' to simulation. The reason being, I completely glossed over the fact you have to change the processor type to Emulate anyway, which definitely can't be done dynamically . It may still have merit to do it automatically in the 'live' version on the controller but I can't ever forsee a reason to quickly move in/out of simulate mode. Definitely not worth the potential of a module getting locked into inhibit mode and getting a 3:00am phone call

averytc said:

Let me start by saying I have not used Emulator, but it is on my list of things to try. I do simulate most of the new processes we install prior to start up. In the configuration of every device I add a simulate option that disables the I/O and simulates it. I add a rung to enable the simulate bits for each of the devices involved while I do testing. The analog is also simulated in the same manner. The simulation is normally used for the first round of training before start up. After the training I disable the simulation function. I don't use tags that are directly aliased to I/O, so this works well for me.

I just saw your update, and I don't see why that wouldn't work. Are you planning to use this for training purposes?

Click to expand...

Yes, that's exactly the purpose, although it has a secondary benefit of proving out my logic and uncovering some typos.

How are you indending on keeping the simulation code without interrupting the real IO? What happens if you leave, and your replacement sees this and enables it?


Be sure to document, document, document. I would even go as far as placing logic in the simulator routine that if all IO cards are not inhibited, then the simulation routine will not work (that is if you are keeping it).

Glad the hear you got it working. I started simulating so that I could prove out my code before I made a fool of myself... Not sure if I've been very successful, but It does work good for training before start up.

Oakley is right. If you intend on keeping it in the program make sure it's well documented.

It's well documented....but I like the idea of checking the inhibits.

I have found something strange, although it only rears its head if you are manually manipulating data. Even though the I/O modules are inhibited, If I write to a tag on any given channel of an analog module, then all other channels revert back to the last known write state.

As an example, I have two tanks with two levels (one load cell, one analog capacitive probe). Let's say through RSLogix 5000 I write a value of 1000lbs to the load cell and 50% to the capacitive probe. I now turn on the simulation of xfering material and the load cell ch decrements while the capacitive probe ch increments due to the simulation logic. As long as I leave it alone, no problems. But, if I go into tag monitor and write a value into the capacitive probe tag (say 30%), the load cell magically jumps to the last write value of 1000. Conversely, if I were to write 2000 to the load cell, the capacitive probe channel jumps to 50%. Very weird, but as long as I let the simulation ONLY write to these channels, there are no issues.

Took me awhile to uncover what was happening as I was manually writing values, tuning in the simulation. Anyone seen this or know why this would be the case?

That is strange. It has to be something to do with the aliased tags. I don't have that issue. This sounds like a question for Ron Beaufort.

What happens if you write the new value by changing the value of the tag in an instruction used in the simulation logic rather than from the tag monitor? For example, if you have an add instruction that is incrementing the level just click on the tag value you want to change and type in the new value.

danny.michael said:

What happens if you write the new value by changing the value of the tag in an instruction used in the simulation logic rather than from the tag monitor? For example, if you have an add instruction that is incrementing the level just click on the tag value you want to change and type in the new value.

Click to expand...

Works just fine...That's exactly what I'm doing (decrementing one analog incrementing another to simulate transferring of material). It's only if in the middle of an inc/dec that I pull up tag monitor and write a value to one tag, all the other tags on that module revert back to the last write value that was written through tag monitor.

Let's say I write 100 and 200 to two tags via tag monitor.

Now I run a rung of logic that increments 100 and decrements 200 by 1 each. At some arbitrary time, the 100 tag is at 125 and the 200 tag is at 175. I write 100 into the 100 tag to start it over. the 200 tag instead of continuing to dec from 175 writes itself back to 200 also.

[FONT=&quot]good discussion. Thank u so much for ur useful posts
simulation credit
[/FONT]

thanks for your help