cantcliff

You typically can't put HMI items in front of other items. I would recommend a screen that the HMI jumps to when you press a button and then use small elements for the other variables.

A coil and a direct contact are programmatically the same and function the same inside the PLC. The difference is a direct contact has an effect on the physical world, where as a coil is logic internal to the PLC only. To make a coil performance physical changes, you need to link it to a direct contact. There are advantages to using coils and energizing contacts with them, and there are also advantages to driving the contact directly.

I'm confused by your formula. Something doesn't make sense to me without knowing the application. Are you trying to find angle (a) or BC?

How do you want to record day/time? The easiest way would be at your event that you need to record, write out SI 30-37 to a file, table, or however you're recording the event. Those are read only because they are actual clock time. Changing those could have very bad consequences. You can store those into a standard integer as well without problem.

Lawry, If the connection is clean, you shouldn't have drop issues. You could try dropping the communication rate to a lower speed. I would also check the terminating resistors at each end of the bus. Another potential problem could be your shielding, double check you don't have a ground loop condition and that at least one end is properly grounded.

Based on the manual it is an error, but it's read related. Have you tried resetting it after recording an alarm to see if it returns immediately?

Is there an input value that each bar links to? Have you initialized that value on startup? I haven't messed with the bar graphs display yet, but to me the output looks correct. Partial graphs based on the values input.

You're running into a common problem using input buttons. The program is scanning several times during the time you have the button pressed. You need to prevent your code from executing your start rung more than one time. There are a lot of ways to do this. I tend towards Positive transition contacts because most my programs are relatively small but those aren't always preferred as they can cause weird issues when you start using a lot of them. I have yet to have issues. You can also work multiple rungs together to control the logic so that a single press one registers for a single scan.

The auto-tune "should" work. It just make take quite a while. If you limit the number of passes it won't take as long.

Just a warning, you may get un-intended communication issues sticking with RS-232. It can work as multi-tap but was never intended. Make sure you have sufficient sanity checks in your program to prevent process problems from bad communication.

RS-232 is a point-to-point protocol. You can't have multiple devices on an RS-232 connection without some very clever work arounds. You want to use RS-485 for multiple devices as it's designed for it.

Hope this goes somewhere. Even is its not sub ms response time, 16 bit would be useful in general.

I would talk to anyone that may have been using it.

Personally, I would look more into a micro controller solution for running an RC aircraft. Something like a decent arduino board or propeller (seems appropriate doesn't it) setup. They run on lower voltages, they are significantly lighter in terms of actual weight (always important when you're talking things that fly), they will allow you to interface readily with many off the shelf solutions like GPS, wireless communications, etc.

Fantastic news! PID can be a bit weird sometimes until you get the tune right but when it works you wonder why you never used it before. Auto-tune isn't always optimal over time, like you've seen, but it makes a great starting point!

As a homebrewer myself I've been looking at building an automated setup using unitronics for my personal system. I'd absolutely be interested in discussing this project with you.

To add to what Joe stated. The raw value is going to be dependent on the bits of your A/D converter. 12 bit = 2^12, or a range of 0 - 4095 14 bit = 2^14, or a range of 0 - 16384 16 bit = 2^16, or a range of 0 - 65535 From there you need to use the linearize function block to get the actual reading using the scale you want, 0-10v, 0-20ma, etc. For example, on a 0-10v sensor, the A/D should output 65535 when it receives 10v and 16 bit, for 12 bit it would output 4095 for the same 10v. The conversion time is in the spec sheet for each snap plugin or add on and it can vary if the input allows you to choose between 12 bit, or 14 bit, with the higher bit depth being slower.

Even if everything has power, the EX-A2X *requires* that the communications module and the PLC are on the same power supply (Page 5 of the documentation for the adapter). I've experience this issue in my own box when first using on of these as I missed that portion of the documentation as well and used a secondary power supply to power the EX-A2X but was having comms issues like you're having. Both units must power up simultaneously as well. How long have they been running that cable? If they wired it as a standard RJ45 network cable it won't work. There is definitely something different about the EXL-CAB100 as even plugging it in backwards can cause communication issues (Personal experience for not reading labels).

You could create a counter at the high and low end of the oscillation that when it reaches a certain value triggers an auto-tune. This is a band-aid fix though, as you shouldn't need to auto-tune frequently unless there is some inherent instability in the system process on it's own. You might want to try manually adjusting some of the PID values after you've auto-tuned to force a more stable system over time. Couple of things that might help: Increase the P-value. Outside of the P range you're valve is either fully open, or fully closed. Increasing the P-Value range (100% is allowed) forces the PID function to always run it's calculations instead of going full open on the valve. Increase the I-value. Larger I-values smooth out and tries to prevent overshooting of the process variable based on the error. It may take longer to stabilize, but it helps prevent overshoot. If fact if you just run a PI system with a larger I-value, you will never hit your process variable. D-Value, I forget which way this one affects the system as I usually set it to 0 for most my applications, but this is your predictor variable. It tries adjust the response based on where it believes the system is going. Strong D values create strong responses to a change in system state and can lead to oscillation. Tweak this so that your system doesn't react as fast, but still catches some of the error.

Could be a wiring issue. *edit* I would double check some of the 0v lines to make sure they are all on commons. I had issues with communications once that was caused by that.

Andrey, Typically yes, if you use 0v as your reference. RS-485 two wire uses the voltage differential between A+ and B- as it's reference on a twisted pair wire. The biggest advantage is both wires would be prone to the noise. So if A+ is offset, B- is also offset by an identical amount and the differential is maintained. There are also a 3 wire spec, and a 4 wire spec (4 wire is used for full duplex communication). As always, you should still use grounded cable with the ground connection on one end to improve performance and minimize noise.

The response time should be the same as the response time of the input. The main variation would come from the program scan time as the immediate read would update the value mid scan instead of waiting until the next scan cycle to update. If your scan time is 20ms and your input updates 1 ms into that, after inputs are normally read, it would be 21 ms before the value changes (assuming logic doesn't affect it). With the immediate function all logic following after the update portion would use the new value, maybe just a few ms to update from the immediate read. This could cause some interesting logic bugs though, with one rung using a different value than another rung than intended due to the update.

RS-485 is a two wire differential protocol for the Vision series. There is no signal ground.

I know certain config blocks state they need to be called every scan, and I have some of those in other programs running both in, and outside of, the main ladder. The order doesn't seem to matter with the NUM to ASCII block though. It only misbehaves when I put it within a subroutine regardless of the subroutine being called every scan. Operand A, start address of the vector, which is not dependent on any logic, shows 0 when I attempt to run NUM to ASCII from outside of the Main!. As soon as I put it in Main! operand A takes on a value. If you'd like I can get some screen shots of the behavior.

You may have to step through the logic for each one to make sure. Anytime something is compiled/translated there's always a chance for error in the final product if the logic doesn't follow a strict guideline convention.