Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: RBPLC on September 11, 2019, 07:58:08 PM
-
I've noticed recently that many of the BRX modules are sold out and back ordered at Automation Direct. Is this due to manufacturing issues or have sales for the BRX and modules been really strong since the release of the newer modules?
-
Which modules are you having issues with? There are no supply issues at Host, although I?m not sure about FACTS.
-
I was specifically looking at a TC module but many of the analog combo modules are showing out of stock.
-
I was specifically looking at a TC module but many of the analog combo modules are showing out of stock.
I think that is due to some firmware issues. Frustrating, but these things happen. I?m sure they?ll get it resolved soon.
There will be some new Host-built options early next year.
-
I take it from your response that FACTS makes some modules and HOST makes others?
-
I take it from your response that FACTS makes some modules and HOST makes others?
Host is the primary developer. FACTS did all of the currently shipping analog modules. Host is also developing some new analog modules with extended features, which we expect to be launched early next year.
-
Can you elaborate on what those extended features will be?
-
Can you elaborate on what those extended features will be?
Certainly.
There are 3 channel types available. Input, output, and temperature, available in the usual 4 channel, 8 channel, and various combos. Standard inputs and outputs are selectable current/voltage by channel. Temperature are universal TC, RTD, and NTC, selectable by channel. Temperature modules also support raw millivolt inputs. Temperatures are reported in 32 bit floats, with considerably higher precision. All modules use internal power, no external 24v required. Standard inputs are fast, ~1.2ms to update all channels. All inputs (standard and temperature) have internal filtering, set per channel.
That?s the high spots. Expected launch is Q1, with the usual disclaimer that they are available when you see them in ADC?s store, and of course, stuff happens.
-
1.2 ms is smokin fast for a TC module.
-
1.2 ms is smokin fast for a TC module.
Temp module is slow. That's just the standard input speed.
-
That is still very fast for Analog. What is the resolution? How fast is the TC module?
-
That is still very fast for Analog. What is the resolution? How fast is the TC module?
Temp module depends on channel config. RTD and NTC are 125ms per channel. TC is 250ms, I think. Those are additive, so a single resistive is quick, but 8 channels of TC is about 2 seconds.. Standard inputs are 1.2ms for all, not additive.
-
I am guessing this is the same problem with getting the analog combo cards? (2 ch current in/out) I hope it is resolved soon.
JW
-
I am guessing this is the same problem with getting the analog combo cards? (2 ch current in/out) I hope it is resolved soon.
JW
Yeah, I think combos were involved. It should be resolved soon.
-
1.2 ms scan rate for analog inputs, current and voltage, sounds very good. :) :) the t1H modules are that fast now so hopefully you can do it too.
-
1.2 ms scan rate for analog inputs, current and voltage, sounds very good. :) :) the t1H modules are that fast now so hopefully you can do it too.
BRX onboard analogs are that fast. The new modules use the same design as the onboard.
-
Hi Bob O.
How are those new fast analog cards coming along?
When I read the spec for the Brick analog inputs I see 1.2 msec conversion time. How are conversion time and scan rate related?
-
Hi Bob O.
How are those new fast analog cards coming along?
When I read the spec for the Brick analog inputs I see 1.2 msec conversion time. How are conversion time and scan rate related?
Expected launch is late March. As with all launch dates, things can change.
Analog conversion is independent of the PLC scan, but the image register is updated by the PLC scan.
The new modules user the same analog chip. Performance is comparable to the onboard channels.
-
Expected launch is late March. As with all launch dates, things can change.
Analog conversion is independent of the PLC scan, but the image register is updated by the PLC scan.
The new modules user the same analog chip. Performance is comparable to the onboard channels.
So, how fast will the PLC scan time be with the new cards.
-
I don't think the analog affects the scan time, I think he's saying that scan time poses a practical limit on effective update time into your logic.
-
I don't think the analog affects the scan time, I think he's saying that scan time poses a practical limit on effective update time into your logic.
Correct. The two devices are asynchronous.
The PLC has a scan time, bound by the limits of the minimum and maximum times it takes to scan the program logic.
The IO cards have their own update time, which is not tied to the PLC scan time. When a card has new data ready it is placed into the backplane queue to be pick up when the PLC gets to the appropriate point in the scan (usually at top of scan).
PLCS do not go ask the card for data and then the card goes out and at that instant the card reads the inputs. Only some digital input cards that have no buffer work that way.
-
Some modules do significantly affect the scan time, but our new analogs do not. We did a bit of characterization and it looks like the scan bump is ~30us per module.
That doesn't include scaling, which will add some additional time per channel scaled.
-
Yeah, the ADC could be 1 microsecond, and if the PLC only looks every 3ms because of scan time, you still have effectively a 3ms update. But, in that case, at least you can improve it by optimizing scan time, especially on a platform with as many tools to do so as Do-More.
-
If you have the analog in a remote rack, what is the added delay?
-
If you have the analog in a remote rack, what is the added delay?
It'll be scan dependent. If scan is short, a few milliseconds.
-
I want to use BRX for an analog process, other PLCs controlling this process the scan time for the cards and rungs is set to 10 milliseconds. The process is high speed rotating equipment that has to be controlled within a few RPM.
The IO cards have their own update time, which is not tied to the PLC scan time. When a card has new data ready it is placed into the backplane queue to be pick up when the PLC gets to the appropriate point in the scan (usually at top of scan).
And where is this "update time" given for the analog inputs on the BRX bricks?
I think the BRX might work, I have to break down and buy one of the bricks with analog input and outputs, wire an output to an input and see what the trends show.
-
I think I'd want an encoder and dedicated motion controller.
-
I think I'd want an encoder and dedicated motion controller.
They use magnetic speed pick ups and a toothed wheel. these are already installed. The pulse from the mag pick up has to be converted to 4-20 ma to interface with the PLC. There are commercially available modules to do this.
(https://3.bp.blogspot.com/-sza9p1zOpoE/Twh6_xQTNsI/AAAAAAAAAes/OZaed8SAjFI/s1600/magnetic+pickup.jpg)
-
If you could bring it in as a pulse, it would be faster. Either way, BRX should be fast enough to do what you want.
-
I saved a ton of money at my last job using BRX High Speed Counter inputs to take pulses from flow meters rather than 4-20ma analog. Adding converters that need to be programmed adds lots of cost and makes your whole system less reliable. That left the analog channels available for thing like pressure, and temperature where analog was really needed. The less conversions the faster and more accurate it will be.
-
For flow, not only is the high-speed discrete point less expensive, but eliminating one conversion is going to reduce error, plus discrete is perfect for totalizing (and likely more accurate as well).
For motion, to convert the gear-tooth pulser to analog is going to require a sample time, which is going to effectively filter your velocity response. In a lot of cases that would probably be fine but if you're trying to maintain a window of a few rpm on high-speed rotating equipment, using analog is handicapping yourself IMO.
So yeah, definitely use the pulses directly rather than convert to analog. As far as the BRX vs. dedicated motion controller goes, I'm not sure the OP gave us enough information to confidently say. I also don't know if the motor driver is a servo amp, VFD, etc.
-
I would be curious to know the expected range of pulse rates. BRX can do a very nice job with stuff like this.
-
I would be curious to know the expected range of pulse rates. BRX can do a very nice job with stuff like this.
What's the best way to set it up? Use the pulse input as an interrupt, I assume? Then what do you do with the control output at sub-scan rates? Are there immediate analog outputs?
Also, his bandwidth capability and signal compatibility on the output side is something I'd want to know more about. Can he accept a pulse train? If he has a VFD, does it want an analog signal, and if so, can BRX compute and output it fast enough and the VFD respond quickly enough to stay in his few rpm window? Are there load variations, and if so, are they sharp-edged or gradual, etc. For that matter, how are "high speed" and "few rpm" defined?
But back on BRX, can you give an overview of the best way to set up this type application? Thanks!
-
What's the best way to set it up? Use the pulse input as an interrupt, I assume? Then what do you do with the control output at sub-scan rates? Are there immediate analog outputs?
He said 10ms was what he was comparing to. Normal scan is plenty fine for that. The question becomes conversion of pulse rate to RPM. If the rate is slow-ish, I'd use a high speed timer in edge mode with the interval scaling function. If the pulse rate is high-ish, I'd use a high speed counter with the rate scaling function. I think there is a very good chance that we'd produce a better result than the converter, and do so with far less latency. I'd need to know the pulse range to make a recommendation though.
-
Oh yeah, better than the converter, absolutely. The converter's a bad idea, though, so I wouldn't compare with that. My concern was "high speed" and "few rpm". For example, if there's a load upset, is he going to be happy if after correction, the speed lands within his few rpm window of setpoint, or is he looking for stiff enough response that it never leaves the window in the first place?
In fact, a lot of VFDs will allow you (often with an option card) to input an encoder directly to optimize speed regulation over just using back EMF as a feedback mechanism. Having done that, you can often also tune the velocity control PID in the drive for more stiffness, if that's what you need, and still eliminate a bunch of feedback and control signal conversion latency.
As I said, I think a lot depends on him defining the terms and criteria in more detail.
-
As I said, I think a lot depends on him defining the terms and criteria in more detail.
One man's real time is another man's batch. The details matter.
-
That's a good line, I'll have to remember that! ;D
-
He said 10ms was what he was comparing to. Normal scan is plenty fine for that. The question becomes conversion of pulse rate to RPM. If the rate is slow-ish, I'd use a high speed timer in edge mode with the interval scaling function. If the pulse rate is high-ish, I'd use a high speed counter with the rate scaling function. I think there is a very good chance that we'd produce a better result than the converter, and do so with far less latency. I'd need to know the pulse range to make a recommendation though.
the source of the pulses is usually a 60 tooth wheel installed on rotating equipment for speed control. The HZ reading is the same as the RPM reading which is convenient. The conventional wisdom says fewer teeth make shaft acceleration harder to calculate. No equipment owner will install a new toothed wheel for a new control system. The operating range is 3000 RPM on up, I dont know the upper limit. Also the speed pickups need to sense very low speeds and 0 speed to engage starters and rachets. The voltage varies with speed, I have seen near 0 volts to 30 Volts AC.
Allen Bradley and the big boys have speed detection cards which can handle speed pick ups on steam turbines, gas turbines, diesel engines etc.
I have seen this, the jacquet T401 tachometer used with Allen Bradleys faster AI cards. Jaquet says to can have a 2 msec scan rate but I have only seen 5 and 10 milliseconds scans used. This module cost about $400.
https://www.istec.com/wp-content/uploads/2013/09/t-400-v2.02e.pdf
I want to use a jacquet with a BRX to control rotating equipment speed. Its a big market, look at all the products Woodward governor makes. On the bigger equipment Woodward has PLC and DCS competitors, but on many smaller applications they seem to have almost no competitors.
Well, I gave away the idea, but as soon as someone else does speed control with a BRX I can follow in their footsteps, easier.
-
Is that a typo or is the converter output actually an analog AC voltage? I don't think the analog inputs are going to deal well with that (BobO correct me if I'm wrong)
If you do a BRX or other PLC, a 3kHz and up pulse will be much too fast for a discrete input unless it has high speed capability (which a portion of BRX inputs do have).
Also, your load is a turbine (gas or steam), but not necessarily for power generation? (Thus the arbitrary speed ranges) Do you actually need a safety-rated control system, or is there a separate dedicated system for overspeed, etc., such that a standard PLC is OK for this functionality?
Can you provide answers to some of those questions I raised earlier? What's a "few rpm"? Can load changes deviate the speed outside the window during correction?
Does the AB card you're talking about do the control output as well as the input on the same card, so that it might actually have a control loop internally, independent of scan time? Their 90's era servo cards worked that way IIRC.
-
Controls Guy,
thanks for your interest.
Is that a typo or is the converter output actually an analog AC voltage?
The jacquet tach above outputs a 4-20 ma or a DC voltage. the input is a sin wave from the magnetic pickup.
Also, your load is a turbine (gas or steam), but not necessarily for power generation? (Thus the arbitrary speed ranges) Do you actually need a safety-rated control system, or is there a separate dedicated system for overspeed, etc., such that a standard PLC is OK for this functionality?
Yes, not always power generation. You have to control and monitor speed from start to overspeed which is usually 112 percent or so. there are gear boxes that change speeds, 3600 rpm for the generator and 5100 for the turbine for instance. Its not always a 60 tooth wheel, sometimes compressor blades or gear teeth or used so it can be 16 teeth per shaft revolution and a 12000 rpm shaft, I think those were the numbers I saw once.
There are separate overspeed systems but sometimes only the PLC is used, not often. The jacquet tach has a contact output which can be used as an overspeed.
Does the AB card you're talking about do the control output as well as the input on the same card, so that it might actually have a control loop internally, independent of scan time? Their 90's era servo cards worked that way IIRC.
No, it was a separate high speed card, i saw this in 2010, the governor calculation was in the software. The high speed card sent a 4-20 ma signal to a valve driver.
-
I'd say the BRX input would work for much of that range, but I'm not confident that it is the best answer. I guess you'll have to use the adapter/converter.
-
Huh. I've never worked with turbines, though worked around some who did. I kind of had the impression the control loop had to be really quick to keep them at the right speed.
But if an AB can do it in software, as opposed to a coprocessing module with only asynchronous supervisory control from the PLC CPU, I guarantee a BRX can do it.
-
I'd say the BRX input would work for much of that range, but I'm not confident that it is the best answer. I guess you'll have to use the adapter/converter.
yes, I will try the jacquet frequency to ma converter at some point.
thanks for the support with my questions.