cantcliff

Be careful using a conditional to set and reset the same coil on the same rung of logic. When the program is compiled to down to code it may not compile how you think and can give weird logic bugs. You can get conditions in the final code where the coil changes states between evaluations and you set and reset the coil on the same pass. I highly recommend separating the logic out into multiple rungs.

Personally I tend to group modules of a like type to prevent the sandwich issue. I also try to standardize it across projects so that I know Outputs are always certain bits and addresses. Other than that, it doesn't affect functionality in any way. Once you have the program finished, unless you've written the program to account for movement, moving modules can be a pain as it changes the addresses. I know this is worded a bit funny. It's early and I'm not fully caffeinated yet to form completely coherent thoughts.

What is your reason for filtering? I ask because there's a built in filtering on the analog inputs you can configure which might suit your purpose just fine.

Keep in mind the PID loop only functions in one direction, heating or cooling. In order to handle both you'll need a logic setup to switch between two PID loops.

As you have no logic in your !Main Module to prevent running the subroutine, the subroutine will run every scan. The easiest way for me, I assign a binary element to the HMI screens and link a coil to it with a bit of a blink logic, so I know that particular subroutine is running every time.

I usually try to stick to one rung, one output. Sometimes I get lazy, sometimes I don't. The only way to guarantee your program works as intended is to do it every time. We had a very weird issue once with a PLC controller test station that popped up after a software update with another manufacturer. Turns out their compile routines changed slightly on how they processed the logic, which changed the order of the final program execution. I've also seen the same issues when duplicating programs across two different manufacturers. You are not alone.

You can use sub-routines for shared sections of logic, though, it's not always as straight forward as you'd expect sometimes.

Short answer yes. Long answer, depends on what you want to do. Most digital inputs work on a voltage/current levels to different signal with a gap between them to prevent dither. I'll use the M91-2-T38 sourcing inputs as an example. From 0-5 volts the input is recognized as 0 (Off). From 17-28.8 volts the input is recognized as 1 (On). Between those numbers your input is floating and you can get unexpected, random results. What this means is if you're analog sensor range is a close match the two point ranges is you can "fake" a digital input using an analog sensor.

According to the documentation: http://www.unitronics.com/docs/technical-library/jz20-t40-jz20-j-t40_2.pdf?sfvrsn=0 You need 20.4 to 28.8 volts for the digital outputs to function.

Automotive DC power is notoriously noisy so you're better off using some sort of power supply convert up to 24V to ensure a clean power signal, at a minimum you should have some sort of power conditioner/regulator to ensure a stable input.

Do you have the make and model of the valve? Here's my assumption right now. The valve has an input to open and one to close. If you apply a signal to open, for 1 second, and then remove signal, does the valve stay open or does it close automatically, in which case, why is there a signal input for close. In my mind, opening the valve leaves it open until you specifically send a close valve signal. My gut tells me to use the temperature as your variable to control the PID but it may have issues because you need to drive two digital outputs from the PLC for control in the

Ideally it would help to see your ladder to better understand what you're doing.

Bill, I think I worked through this before. You cannot directly change the drum sequence step time. There is a work around. If you use 0 time for the step, you can use a timer to trigger the next step function block when the time runs out. The timer duration can be set through variables.

More accuracy is never a bad thing, unless it's cost prohibitive. I forgot to say above, I would go with option 2, logically it's the easiest to implement. I would probably set the P band to 100 percent for your application and see how the system responds. If it still has issues on start up, I would consider option 1.

I think the solution to your problem is your startup sequence. The PID *should* turn on automatically at start up and be functioning immediately. What I think is happening. The PID loop is outside the P band, so it's going to turn the motor on full until it gets within that band. There's multiple ways to address the problem. 1) For your stop sequence try storing the current control value to another integer. Disable PID. On start sequence set the output to the control value integer you stored for a few seconds, depending on how long it takes to get spinning, then enable PID.