The 462 is finally wired.

Post pictures of your System
User avatar
ECC
Posts: 676
Joined: Fri Sep 12, 2008 12:29 pm
Bot?: No
Contact:

Re: The 462 is finally wired.

Post by ECC »

That sounds like its working as expected. By unchecking the "Control" box for that output, the Process is giving up all control over it. If the output was ON when you gave up control, it will stay ON. Since the Process now doesn't 'use' that Output, it will make no attempt at turning it off when the Process is disabled. If you want to force it off, select Direct Control OFF.
User avatar
bbrally
Posts: 210
Joined: Sat Mar 27, 2010 3:59 am
Bot?: No
Location: Vancouver, BC
Contact:

Re: The 462 is finally wired.

Post by bbrally »

It all makes sense now. I'm so glad this was my problem. Thanks
User avatar
bbrally
Posts: 210
Joined: Sat Mar 27, 2010 3:59 am
Bot?: No
Location: Vancouver, BC
Contact:

Re: The 462 is finally wired.

Post by bbrally »

I have a couple of questions out of curiosity.

When I run the simple process mentioned in the previous posting, out0 turns off after pressing win0 even though I've unchecked the out0-control and the out0-direct controlled boxes. shouldn't this also leave out0 on?

What was the reasoning behind having three levels of control on the outputs. 1. There is the enable in the system settings. 2. There is the control per state. 3. There is the on/off per state.
JonW
Site Admin
Posts: 1726
Joined: Sun Jul 18, 2010 7:51 am
Bot?: No
Location: Huntington Beach, CA
Contact:

Re: The 462 is finally wired.

Post by JonW »

I think part of where your confusion is coming from with the logic functionality is that you are trying to interpret the control logic during both "setup" and "runtime" control. I generally do not change any setup options while I am running processes. If you have a process/state running and you change it's options on the fly, which logic should it use? The logic when it was started or the current logic saved? There's no simple question to that because it may be dependent on the current system state and what the inputs, timers, etc. are doing.

Try to keep setup and runtime options separate and just focus on how the system operates when it runs. During a normal brew day, you should not be modifying your processes in the middle of the process.
User avatar
bbrally
Posts: 210
Joined: Sat Mar 27, 2010 3:59 am
Bot?: No
Location: Vancouver, BC
Contact:

Re: The 462 is finally wired.

Post by bbrally »

I totally agree that during brewing the setup process should already be complete and changing settings shouldn't require doing.

But reality and the perfect world rarely collide in my house.

During my first brew on the new brew stand I encountered a few issues that required changes on the fly. I would have done that in the manual mode, but Expansion card outputs cannot be manually changed, thus changes to a process are required.

Now I am only trying to understand how things run so I can avoid any future issues, and possibly design my custom interface better with less trial and error.
User avatar
ECC
Posts: 676
Joined: Fri Sep 12, 2008 12:29 pm
Bot?: No
Contact:

Re: The 462 is finally wired.

Post by ECC »

bbrally wrote:When I run the simple process mentioned in the previous posting, out0 turns off after pressing win0 even though I've unchecked the out0-control and the out0-direct controlled boxes. shouldn't this also leave out0 on?
Not if state1 is controlling it direct OFF. You unchecked the control in state0, but is state1 still controlling it?
bbrally wrote:What was the reasoning behind having three levels of control on the outputs. 1. There is the enable in the system settings. 2. There is the control per state. 3. There is the on/off per state.
This might seem a little confusing, but it is definitely needed for advanced users trying to control the same output with different processes. I think you've hit all around this on your other posts. Think about it this way, if one process tries to control ALL of the outputs, and another process tries to do the same, who wins? That is where process priority takes over (higher process wins).

But by having a 'control' enable per output, it allows processes to only control a subset of the outputs, so that they won't collide with other processes.
Post Reply