Total beginner, Crimson 3.0 Questions

[kolyur]

You could assign your PLC "System OK" bit to a tag, and use that tag in the Enable field of the button properties. This would prevent the user from operating the button unless the bit was on.

 

[cgibsong002]

You could assign your PLC "System OK" bit to a tag, and use that tag in the Enable field of the button properties. This would prevent the user from operating the button unless the bit was on.

Ha, geez, I thought I had it all figured out on my drive home but that's a heck of a lot easier. I was going to say I could use an if then statement again to say if System OK is off, always write 0, and if System OK is on, then write the opposite of current state. I guess it's exactly the same but using the Enable field is much simpler!

Now, if that button is protected by System OK in the Enable field, is it completely redundant to have it in the PLC logic as well? I'm going to leave it anyway for troubleshooting purposes, but are they essentially doing the exact same thing?

 

[kolyur]

Now, if that button is protected by System OK in the Enable field, is it completely redundant to have it in the PLC logic as well? I'm going to leave it anyway for troubleshooting purposes, but are they essentially doing the exact same thing?

There are times when I will create duplicate logic in the HMI and PLC, just to make sure it executes in the event of a comm fail or something. In your case, however, it might not be a good idea since you are using toggle style buttons. Like we've both said, I don't how the HMI will respond if the PLC starts overriding the bits. You could easily do a test to find out.

Another possibility would be to do all of your logic in the PLC, and the HMI would just notify it when a button has been pressed. Set all of your buttons up as Momentary NO type. Then in the PLC, create logic to look at those button bits and do the proper actions when they go true: toggling the valve outputs or turning them all on or off (one-shots may be required; I don't know Omron). The advantage of this is that you're not splitting your logic between two devices--this might make troubleshooting easier a few years from now.

A lot of it just comes down to personal preference--what makes the most sense to you.

 

[cgibsong002]

I know there's an emulator feature, and after reading through the manual, I'm still struggling to find much use for it. Is there a way to simulate the pressing of buttons or changing of bits without any hardware attached? For example can I set Valve1=1 and watch the switch move? Or another indicator=1 and watch it light?

 

[kolyur]

The emulator works best if all your tags are internal. That is, if you don't have any tags mapped to external devices. The emulator can do communications (see the manual) but this is too much of a hassle in my opinion.

I normally don't test my entire project with the emulator, but rather individual parts of it where I'm not 100% certain how a particular feature or program will work. I'll mock-up a quick file with just that one feature and run it through the emulator.

EDIT: Unfortunately the emulator probably won't help if you want to test the button toggle issue, unless you go through the whole rigamarole of getting comms working. It might be worth an email to Red Lion tech support. They've been pretty responsive in my experience.