Definition of "programmable" - straw poll

Only guessing, go from speed S1 to S2 over a period of t second linearly, I would think would be soft ware. Not a expert in this field.

Regards JD.

"In the application, the rates will not need changing once the system has been commissioned"

Hi, in the long term, are you absolutely sure? Maybe the client is anticipating future mods and is try to "future proof" his forthcoming investment.

Absolutely sure. This kit is replacing another I designed, installed & commissioned about 15 years ago. I set up the motor speeds (as parameters stored in NVRAM) while commissioning, and I've serviced the system twice a year since. Neither speed nor acc/dec rates have needed to be changed.

Also, the ability to change the rates with a pot or DIP switches still gives to possibility of future change if something completely unforeseen happens (value of g changes? ).

I agree that using a pot or a set of dipswitches as an input could be considered as a programming input, and they can be changed later - but they are not under programme control. The obvious thing to do is go back and ask the question.

Could be that agreeing to s/ware solution adds $$$ to JohnDGs cost. If tender accepted & client really wants s/ware answer, he'll have to pay the extra.

Reading it again suggests that maybe the customer would like to fine tune his process, particularly if it has a number of different stages, and reading your other posts, and your involvement, I suspect that you may have a nagging feeling, if you know what I mean. But asking him to be more specific does seem the way to go?

Regards JD.

Ramping a setpoint up and down at given rates is a relatively simple thing to achieve within a programmable logic controller. If there is to be no change following commissioning, then a few lines of simple code would be needed in each case; 20min initial programming, tops:

• Start a timer that runs during the ramp-up time.
• divide the elased time into the setpoint time to obtain a fraction.
• Multiply the design full speed by the fraction to obtain an instantaneous speed setpoint.
• Bung the instantaneous setpoint into the motor speed controller.

The ramp-down calculation is similar, except that it uses 1-(the fraction) as the input to the speed calculation.

Point taken, but if the PLC doesn't already have analog outputs, another module will have to be bought in. Maybe not a big expense (depending on the budget available), but it all adds up!

John,

Since both the software and hardware solutions are digital and field adjustable, they are both by definition "programmable". However, if the "Control Unit" is defined in the specification, you would have to use that definition to determine the context.

If you're using a plc, either option is simply putting a setpoint value into a register. Nothing you've stated indicates any requirement that the control have a feedback loop.

Tony

In the world of specsmanship, "must have" is not really a requirement. However, I think that they meant "shall" in this instance.

The actual meaning is ambiguous, except to the customer, which he may not even know.

You need to negotiate the real meaning with your customer. That is "what" you should do. "How" you implement that requirement is your low level requirement, unless that "how" is specifically stated in your customer's statement of work.

The bottom line is that it doesn't matter how I interpret or how anyone else on this board interprets that requirement. YOU have to satisfy your customer's requirement the way your customer intended.

Talk to your customer, not us.

Have you asked the customer what he means by the spec?

I can only assume that if the speed and acc/dec rates are adjustable and won't need to be changed, the customer would be satisfied. As for the definition of "programmable," I think you can stretch (an not by much, if any) the meaning to include pots and/or DIP swithces.

Bill, A. Hero & others,

Asking the customer, at this stage, ain't that easy. This is, I admit, a bit of a far-fetched example, as I'm on very good terms with the customer, and have a dam'd good idea of exactly what they want, and what I'm going to give them!

The reason it's not so easy is that any question I ask the customer, and to which they reply, is relayed to all other tenderers. Maybe none of the others thought of the DIP switch/pot approach, so I may have a commercial advantage, which would be lost if I even asked the question!

This is one example, however, of how important it can be A) for a specifier to get their meaning crystal clear, and B) for a tenderer to know how to interpret the customer's requirements and produce what they really wanted (even if they didn't express it well), without either under- or overengineering the solutions.

Hope I'm making myself clear - I'm a bit pushed for time. I know what I mean, anyway .

The word "programmable" is not limited to software only. Your hardware solution may also be termed as programmable and it can be done so that the difference is lost on the customer. A selector switch will work just as well as a DIP switch or a pot.

However, for maximum flexibility, doing it with software is the way to go. With hardware, a change may require re-wiring the system whereas, with software, it's just a matter of making a program change.

We have Allen-Bradley drives in our factory. The newer ones are connected to the PLCs via DeviceNet. This enabled us to change the parameters through the PLC and ultimately, through the HMI (human-machine-interface).

My old company (an instrumentation contractor) faced the same dilemma several times. Oftentimes, we'd be the highest bidder because our system exceeded their requirements. About 50% of the time, our quote would be taken because we understood the requirements in ways that nobody else did.

You should submit a RFI regarding this to the client. This will show to the client that you are considering the system requirements, and keep from potentially alienating them by asking late in the project or delivering something they had not intended.

See post #12. Once the tender is accepted and the order in place, a preliminary design would be submitted which would bring the proposed "programming" method to light before anything was built - before even detailed design & specification of system components. If the customer agreed with the proposed method, all would be well. If not, negotiations would begin. No alienation would be necessary, and it would never get as far as building an inappropriate solution, let alone delivering one.

Another consideration is who is going to be able to make the speed changes. Pots only require access + a small amount of knowledge, dip switches a bit more knowledge, programming would have the highest level of potential security.

Today I finally received the purchase order for the system in question.

I did not ask the customer, but when I put my tender in, I sent a covering letter explaining in detail the methods that would be used to "program" the speeds & accelerations (ie pots & DIP switches). The customer was happy with it, and has accepted it without change.

Thanks to all who contributed to the thread,

John.