New features wanted!! Apply here!

[franji1]

Another thing that came up, would there be any form of "redundancy" available?

If you mean "hot backup", we've talked about it, but that's it.  Not sure of the demand (like DNP3).

[pravp]

Thanks for your quick responses Jack.

From a marketing perspective at which level do you forsee the new PLC sitting when compared to the competition?

For example,

if we take AB will it sit at: compactlogix or controllogix level?
if we take Siemens: S7-300 or S7-400?
GE: Versamax, RX3i or RX7i?

Just to let you guys know to remove any doubt we (KAPP Engineering) are value added resellers for ADA in Western Australia

[franji1]

I can't really discuss the details, but it's not high-end, and it's not low-end.  We're leveraging some of DirectSOFT and the Direct Logic line.  That's all I can say.

[davenoiz]

I'm currently testing a dl260 system using a dd2-d to simulate conditions. what i've found is that the Click program allows "and above a join" but the DS5 does not. what gives? It seems simple to me, "if X1 and not C3 then Y2 and if not C1 then Y3".

Is it my programming logic style? Could you fix that?

[franji1]

That functionality is implemented via the MLS/MLR instructions in the PLC.  Please review the PLC manual.

It would be nice if DirectSOFT some day would auto-encode those instructions into the rung style you describe.  We've gotten this request before.  It's on our "todo" list, but it tends to get pushed down below other "important" features.   

[BobO]

Another point related to mid-line outputs...

It is easy to draw in DSP, but would also require some manageable but non-trivial changes to the ladder compiler. As Mark alluded to, however, there is no direct way to code the logic...the DL controllers simply don't have the instructions to do that. It can be done through MLS/MLR, but the use of such could cause issues with the hand-held programmer, or more likely, the hand-held would cause issues with us.

That is something that we would like to sneak into our new controller, and we think the logic could be pretty easy, but the changes to DSP are more than we want to commit to for release 1. That is a fairly high priority thing for future releases, however, and we do expect to get it in eventually.

[mike@dcsamerica.com]

Hi,

I think this is a feature request (unless the technical support at AutomationDirect was incorrect with what they told me).  I would like to see real bumpless transfer in the DL PLCs.  I have tried this in the DL05 and 06 and assume all the DLs do the same (maybe not), but bumpless transfer is not bumpless when there is an error between the setpoint and the process variable (trying type II bumpless).

Here is my scenario:

I have a fast (e.g. 5:1) proportional gain and a very slow (e.g. 5 minutes) integral in my PID loop.  I'm in manual mode with my output at 50% and I change my SP to 75% and my PV is currently 25%.  When I change from manual mode to automatic mode, the controller should (depending on direct or reverse acting) start at 50% output and slowly start integrating up the output 50.1%...50.2%...50.3%...etc.  Try this with any controller (other than a DL) and this is exactly how it will perform (bumpless transfer).

While changing the SP to equal the PV (Bumpless mode I in the DL PLCs) will essentially make the transfer bumpless, that isn't what I want, I want the SP to be what I set it to.  With the current DL PLCs, there would be a huge jump in the output in my scenario because of the error between the SP and the PV and the high proportional gain setting.  The way I understand the manual, the way the Bumpless Transfer II works is by writing the current output to the bias value in the PID upon transfer.  This should also include the current error calculation between the SP and the PV to have the transfer be truly bumpless.

This change would be greatly appreciated and bring the DL PLCs more in line with the competition.

Thanks,

Mike E.

[BobO]

Yep, you're in the right place.

This topic is being used primarily for folks to let us know what they want, but since we have no control over existing DL PLCs, we are using the info to help shape the new control engine and PLCs that Host is developing.

We are definitely not PID experts (although I can spell PID and have stayed at a Holiday Inn Express ) and would welcome any feedback (yes, pun intended!) that you can provide to help tune (*rimshot*) our implementation.

Seriously...we'd love your help.

[plcnut]

Mike E.
When I change modes on my loops, I write my own bias values. You can add the error to the bias in ladder and write it back to the Loop Table Starting Address+4 and it is read-on-the-fly. That was my workaround. If it was built into the loop setup though it would be nice.
Jason

[Controls Guy]

That's sort of what I do.  I don't even bother using the PID's internal manual mode.

[BobO]

OK...let's make sure I understand...

Normally, this happens at manual to auto transition:
if(PositionMode)
   PID.Bias = PID.Output;

And during a normal auto update:
PropTerm = ...Calc PropTerm...;
PID.Output = PropTerm;
PID.Bias += ...Calc IntTerm...;
PID.Output += PID.Bias;

The problem is that with a big error, the proportional term rocks the Output, yes?

So, you want this at manual to auto transition:
if(PositionMode)
   {
   PID.Bias = PID.Output;
   PID.Bias -= PID.Gain * Error;
   }

In essence, just subtract the proportional term from the Bias so that the proportional term plus the Bias is equal to the original Output, yes? From that point, the only change to the Output would come from the integral term, or further change to the Error.

Am I understanding?

[Controls Guy]

That's what I took the OP as requesting, BobO.

[plcnut]

In Layman's terms: As the PV fluctuates around the SP, the Output fluctuates around the Bias term. So if, while there is a huge difference between the SP and PV, we bring the Bias term (Bumpless transfer II) to equal the current output; then the next output will create a huge bump, because the huge error that the PID calculation produces will be added to the bias term, which is now (in Mikes example) at 50% of the full scale output. The only way the process can remain steady is for the bias term to equal the current output (50%) minus the current PID's calculated error(not the error between the SP and PV, but the error that will be added to, or subtracted from, the bias value). This may be exactly what Bob just said, but this is my understanding of the problem.    Jason

[BobO]

That is pretty much what I described. We essentially zero out the integral term and offset the proportional term, and the derivative term will be 0 anyway. That means that unless there is a change to SP-PV, the only change happening at the first automatic update is the integral term as it integrates error. That should produce a nice smooth transition. Might be so smooth one might call it 'bumpless'.

[mattclark]

Add in the feature to Directsoft that when you print out the cross reference table you get a graphical image (and, or, etc..) along with the boolean command.