Total beginner, Crimson 3.0 Questions

[cgibsong002]

Can you post your CD3 file? That would probably make it easier for us to help you. I'm not sure exactly what primitives you're trying to use.

Unfortunately I don't really think I can due to company policies.. but if necessary I can even just mock up a quick version of what I'm doing with just the switches I'm working with in place.

Though it may be enough to say that I'm trying to use an Illuminated Button 1, latching. I tried using a standard action pb with the same results. Then I tried a 2-state toggle with actions set to automatic, and value set to complex, and I received no errors with the code. However, that won't quite work for what we're looking to do.

I'll upload a version of what I'm working with so you can take a look.

 

[kolyur]

So, am I correct in saying that you want the button to function as a toggle, but the complication is that you want to control three different tags simultaneously?

 

[cgibsong002]

https://www.dropbox.com/s/gq9qabp8gy6t2xq/switch test.cd3?dl=0

Link to cd3 file. The gist of it is, I have 3 valves (3 DO's) each with positive feedback (3 DI's). These will be split into two screens. The main screen will simply have the 'All Valves' button with the 3 indicators. Page 2 will have the 3 individual switches for troubleshooting if it's needed to check each one on its own.

I originally created another control tag "AllValves" for the main swtich, where in the ladder logic that switch activated all 3 switches (instead of doing in in Crimson). But doing it that way there's a lot of problems with them all playing nice together.

For example, if I turn on all 3 valves on their own, the "All Valves" switch needs to flip to indicate they're all on (in addition to obviously the 3 indicators... I guess we can ignore the indicators here). If the "All Valves" switch is on, and "Valve 2" is pressed off, then "All Valves" must indicate off while "Valve 1" and "Valve 3" remain on. If less than 3 Valves are on, the "All Valves" switch should appear off, and upon pressing, should set the remaining off valves to 'on'.

So it seemed to me this is a bit more complicated to try to do with ladder logic, but it seems like it would work if done on the Crimson side with the "All Valves" switch being used to simultaneously write 1's to all when on and 0's to all when off, regardless of state.


edit: the point is that it must be obviously intuitive for the TS operator. Pressing the main button should always make sure all valves are on, and pressing it off should always turn off all valves. But then all three need independent control as well. It's my assumption (hopefully), that if All Valves writes on to Valve 1,2,3, that if I then go to look at those three valves, they will all appear on since they're also reading that same register. But then if I turn off All Valves, will each individual valve turn off, or will they still read on?

 

[kolyur]

If the three valves are in different states (say #1 and #3 on, #2 off), then what should be the effect when tapping the "All valves" switch? Turn them all on or all off?

 

[adisharr]

So I hope I've stumbled upon a good source of help. I read the FAQ's but didn't see anything pertaining to specifically what type of material is ok to post here so please let me know!

I'm an EE working for my first time in Red Lion Crimson 3.0. I'm unfortunately pretty much just teaching myself how this all works. I'm developing a touchscreen and for the most part it's all very simple, I have my assortment of indicators and switches with everything tagged. I have a few items that are a bit more involved though that I'm unsure how to go about.

I'd like a single indicator to turn green only when a collection of conditions are met. I have three inputs, when all three are on, I'd like the indicator to turn on. I'm assuming this is done on the Indicator>Control>Status>Complex window (rather than using simple Tag), but I don't know how to write the code or what it's looking for. The help manual doesn't seem to say much for what type of coding it's looking for.

Could anyone provide any help here?

Thank you! Looking forward to learning.

You might also want to do the logic in the PLC instead of the HMI. The Crimson platform is very powerful but can result in some additional troubleshooting time when you have some of the logic both places.

Enjoy your new experiences! It's always satisfying when you see the end result

 

[cgibsong002]

If the three valves are in different states (say #1 and #3 on, #2 off), then what should be the effect when tapping the "All valves" switch? Turn them all on or all off?

check above in my edit. If #2 for example is off, then "All Valves" should be off, as it should be both a control and indicator of all 3. So the operator knows at least one must be off. So then tapping the "All Valves" button should turn all 3 on (also indicating now as on).

 

[keshik]

That could be it. I was under the impression my expression would return true/false if used as a status, and write to all three if it was a control.

When you say it like this it makes me wonder if you're using the correct operators ("=" or "=="). If you use a "==" then you are always comparing the two for equality. If you use using "=" or ":=" then you are always assigning one value to the other. There's no context sensitivity to this (for example, different dialog boxes cause different behavior).

I was thinking that didn't make sense though but couldn't find anything else. Is the ':=' statement standard PLC logic, because it doesn't appear to be listed as an operator in the User manual I pulled off the website?

The ":=" is probably a holdover from a previous version of the Crimson software. Structured text, a common PLC programming language, uses the ":=" operator for assignment so it may have some roots there.

Anyway, I'll give this a try. How exactly does it work? Does it force all 3 to true regardless of state when switched on? And the opposite when switched off, if I'm using a latching switch?

I would post a copy of your project or at least a screenshot of the part you're referring to. I think most of us here are a little confused at this point.

 

[cgibsong002]

I would post a copy of your project or at least a screenshot of the part you're referring to. I think most of us here are a little confused at this point.

Ha! I feel it's much more simple than I'm trying to explain. I know usually you just have one toggle for one action. But the thing is 99% of the time the operator will turn on/off all simultaneously, so we want a single button to control all. But we still need a background access to test each one on it's own.

As I said I originally did this in PLC logic, but there seems to be some issues doing it that way.

 

[kolyur]

Your individual valve controls should be OK. I made a few modifications to the "All valves" control. The Status can remain the AND combination of the three valves. I changed the button Operation to Custom, which means it is controlled from the Action tab. I set up a complex code action which I believe does what you're asking.

 

[kolyur]

I realized that my complex code was somewhat redundant. This is simpler and would work the same:

// If all valves are on, turn them all off.
if (Valve1_TS && Valve2_TS && Valve3_TS) {
    Valve1_TS := false;
    Valve2_TS := false;
    Valve3_TS := false; }

// Otherwise, turn them all on.
else {
    Valve1_TS := true;
    Valve2_TS := true;
    Valve3_TS := true; }

 

[cgibsong002]

First of all, I'm blown away by the help I'm receiving. Are you guys getting paid for this or something? Or just because you enjoy it? Either way thanks a lot for everyone's help.

Second, I'm trying to go through all the possible scenarios of how the operator would use this, and your above code appears to be exactly what I was trying to do. I found a good Allen Bradley structured text doc that explains what you did there. I have a few questions just as I'm trying to make sure I fully comprehend.

1. There are slight differences in language. elsif compared to else if, {}'s instead of <>'s, true/false instead of 1/0... are these differences in manufacturers/programs, or are there multiple accepted types of structured text? For example would Crimson interpret each of the above just the same?

2. I see how your original code was redundant. It should still function exactly the same though, correct? I'd like to keep that redundant part there so it's easier to see exactly what is going on if I were to look back at a later date. It seems ok to me.

3. Does every one button have full authority over each button of the same tag? For example, if I have all 3 valves set to on, then press the All Valves button, there won't be a conflict between Valve 1 saying "I'm on" and All Valves saying "Turn off", will there? It should simply say "write to zero", and then Valve 1 therefore automatically changes to indicate that a zero is present.

4. In the case of varying states, where you tell all to be true... if one is already true, I assume it simply remains true?

5. The doc I'm reading states to use End_If; to finish the argument. Is this missing or simply not necessary?

 

[kolyur]

First of all, I'm blown away by the help I'm receiving. Are you guys getting paid for this or something? Or just because you enjoy it? Either way thanks a lot for everyone's help.

This forum has saved my behind on more than one occasion so I try to return the favor.

1. There are slight differences in language. elsif compared to else if, {}'s instead of <>'s, true/false instead of 1/0... are these differences in manufacturers/programs, or are there multiple accepted types of structured text? For example would Crimson interpret each of the above just the same?

I think the programming in Crimson is closer to 'C' than structured text. Either way, it has its own nuances and you really have to read the manual to get familiar with the little details you mentioned.

2. I see how your original code was redundant. It should still function exactly the same though, correct? I'd like to keep that redundant part there so it's easier to see exactly what is going on if I were to look back at a later date. It seems ok to me.

Yes, it should function exactly the same. If you think the first version is easier to follow then by all means use it.

3. Does every one button have full authority over each button of the same tag? For example, if I have all 3 valves set to on, then press the All Valves button, there won't be a conflict between Valve 1 saying "I'm on" and All Valves saying "Turn off", will there? It should simply say "write to zero", and then Valve 1 therefore automatically changes to indicate that a zero is present.

Buttons in Crimson only write to the associated tag when they are pushed (or released). There are ways to make them write continually but this is generally not necessary. So, there is usually not a problem with having multiple actuators point to the same tag.

4. In the case of varying states, where you tell all to be true... if one is already true, I assume it simply remains true?

Yep.

5. The doc I'm reading states to use End_If; to finish the argument. Is this missing or simply not necessary?

Look at the Crimson manual for the correct syntax. You'll drive yourself crazy trying to translate from some other language. The chapter "Using Programs" in the manual (page 213 in my version) is well worth reading.

 

[cgibsong002]

Thanks again SO much.

ALMOST finishing up. So, how does Crimson handle a selector switch when the status doesn't agree with the control? I realized I'm not confident in the way I have the statuses equal to the control. I have interlocks in place in PLC coding, so I don't want the operator to have the impression he's engaged a valve when in fact there are still conditions holding back from doing so.

I remember discussing this with the guy who's previous projects I'm studying. He said he tries to avoid having control and status differ now to avoid not knowing the true state of the coil. But it seems to me the opposite is true. If status=control, and conditions are not met in logic, the status will always change with a button press leading the operator to not know whether the coil (in this case valve) is actually actuated. The switch would turn on, and status indicate on, even if the full circuit is incomplete.

In an older project, it appears he did it with the status equaling the coil (output), and then used latching I guess to ensure the selector would always have the same function when pressed. So I guess in this case, if the button is pressed without conditions met, everything remains off. If conditions are met when pressed, everything turns on and stays on.

However, on a newer project I'm looking at, status=control, and there is no latching in the ladder logic. So I would think without all interlocks met, the switch just turns on and off without any real knowledge of what's going on (without viewing the live ladder logic). He's also self taught though so I'm unsure if I'm misunderstanding something, or if he was making a mistake on the newer projects.

 

[kolyur]

I'm speculating a bit here because I haven't worked much with the status/control options (this is a new feature in Crimson 3 I think).

Generally when you have tags that are read from a remote device, the Red Lion will continually poll the state of the tag whenever it's needed (i.e. displayed on the screen). So if the PLC changes the value, you'll see it update on the screen fairly quickly.

Writing is a different story. As I mentioned before, the HMI usually only forces a write on a value when you initially make the change. There's nothing that prevents the PLC from changing the value later on and the HMI won't know it.

So.... if you're concerned about the operator seeing the actual state of the valve output, you should be safe to put that tag into the Status field and it will continually poll the value regardless of the Control tag.

I'm not sure what happens if you have Status=Control and you use a Latching or Toggle button. Let's say you hit the button to turn the tag ON, but later the PLC turns the tag OFF. The Status should update to reflect that, but if you tap the button again I don't know if the HMI will try to turn it OFF (since it previously turned it ON) or if it will try to turn it ON (since technically it knows that the PLC turned it OFF).

 

[cgibsong002]

I'm not sure what happens if you have Status=Control and you use a Latching or Toggle button. Let's say you hit the button to turn the tag ON, but later the PLC turns the tag OFF. The Status should update to reflect that, but if you tap the button again I don't know if the HMI will try to turn it OFF (since it previously turned it ON) or if it will try to turn it ON (since technically it knows that the PLC turned it OFF).

Hm. Yeah that's more or less what I don't understand. Except instead of my PLC changing states, it's more of a situation like where I have Valve1.. System OK... Valve On, where Valve1 and System OK are the conditions for Valve ON coil. So if the system isn't OK, I can press Valve1, which goes green, but the coil remains off.

In this scenario I always know the state of the switch, but not the coil.

If I set the status equal to the coil... and system isn't OK... then upon pressing Valve1, nothing happens even though Valve1=1 now. Say the operator hits the button a few times not realizing the issue is that the System is not OK, and now all of a sudden he has no idea what position Valve1 switch is in. This raises a dangerous scenario where your valve is on, the operator does not know, and readies the system so now the valve instantly turns on on accident.