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.

I, personally, wouldn't use a full on PID algorithm for this. I would go simple with a poor man's PID. I would create a 5 second timer, longer or shorter as needed, that calculates current frequency from the encoder, then increment or decrement the voltage going to the controller if it falls outside a certain range.

To set PID for P only you assign a value of 0 to the I and D variables. Your wording makes it a bit harder to understand what you want to do though, to even know if PID is right. 1) What exactly is the motor driving? 2) Are you expecting load changes on the motor? 3) Will the motor run at constant speeds? 4) You want to use pulses per minute (or second) to specify the output voltage? P only PID doesn't have scaling. Your process control signal to the motor is either 100% on or 0% off outside of a defined range like +- 10% of target (There's other hacks you can use with P only but it's not ideal) the ID portion allows for scaling based in the process values deviation from target. -Chris *edit* Also, some motors have a form of PID built into the controller which could lead to two PID loops fighting each other for stability. Do you have the make and model of the motor and controller?

Craig, Exactly. Depending on the application it's usually a good idea anyway for mechanical relays. Solid states it doesn't matter so much as long as whatever you're controlling isn't mechanical either.

From what I can find in the general documentation. Low - Last two readings Medium - Last 4 readings High - Last 8 readings I'd recommend putting in some form of a de-bounce function to help with the relay chatter. The High filter will help a bit, but it can still lead to the same problem.

Force Integral Error only allows you to change the current error value while the system is running. It doesn't calculate anything for you. You can set it to anything you want, it just forces the PID to react accordingly. You can use this to "bump" the system while it's running and simulate an event. I typically use this to test my PID loops for stability.

I'm not a PID guru by any means but from my understanding of the math you can't back calculate a value to start at. You can guess sufficient values to slow down or speed up the initial response but you can't bring out the past to identify the best value. PID doesn't use history to make adjustments to the outputs. It looks at the current error, the accumulated error, and adjusts the outputs based on the instantaneous difference between the two and the settings for the different coefficients. At best you trial and error for your initial value and go from there.

Any chance it's set to current versus voltage?

I did not load your ladder as I don't have access to software where I'm at to run it. It may be the way your logic is running. If you're not catching a rising or falling edge, as long as your increment function is active it will increment each scan when the pulse is active.

Are you using the law of sines? https://en.wikipedia.org/wiki/Law_of_sines From what I vaguely remember if you get a negative result, the angle is still valid, however if means you're moving in the opposite direction around the unit circle. To convert to a positive angle, simply add 360 to it. However, you're using a non-standard notation for me, so I'm not sure if you're using the correct numbers, angles and side length, in your equation to spit out good numbers. Typically, angles are represented with capital letters, and the side opposite the angle is a lower case. See wiki link above, or post an image of your triangle with everything labeled.

In theory you need two lines of ladder logic to do what you want: [ MB] --- (O4) [/ MB] --- (O5) When MB is 1, IE, your button is pressed, O4 energizes and O5 de-energizes When MB is 0, IE, your button is not pressed, O4 de-energizes, and O5 energizes.