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. However, you want to create logic to prevent rapid state changes when you approach the 5v or 17v values. If there is a lot of noise you could have very high frequency state changes that could cause some nasty problems, such as running a relay faster than it's switching limits. However, if you want to read the analog input in and use the analog value, the answer is no. You get can only get On or Off I apologize if the answer feels a bit disjointed. I'm still caffeinating this morning. *edit* More proof of lack of caffeine. I may have read your question wrong. If you want to use an analog in as digital in, you would create logic (assuming analog signal), to turn on above a certain level, off below a certain level. From there you would want to add some de-bounce logic to prevent noise from the analog input affecting your state. You can also connect a digital input switch to the analog input as long as the voltage range is safe. You'll still need the above code to turn your state on and off though.

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 PID loop and I can't see the logic to an effective way to do that in my head yet. But that's all dependent on how the valve actually runs. *edit* If all that holds true, then PWM won't necessarily work as intended.

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. 2) Increase the P band range from 5 or 10% to 25%, or 100%. This allows the Integral portion to start calculating earlier, however, it can slow down the overall response. 3) Decrease the time between calculating your RPM and the PID response time. This one might not be possible with your current setup or system to get stable results.