Tag

Just want to see what Rabbit Hole this going down...

BEMF?

Isn't that basically what the BEMF capability in some decoders is designed to do - adjust the speed in response to varying load?  The trouble is that each decoder "thinks" it wants to go a different speed.  If both decoders have been speed matched properly, then BEMF should make the operation extra smooth.  Without prior speed matching, the engines will still be fighting with each other.

Now, if you had a master/slave option, you could allow the lead unit in a consist to be the master and respond to speed commands, while the remaining slave units would simply try (using BEMF or some other logic) to do whatever the master unit is doing, which as you noted can be done without any communication and simply by sensing the load.  Since decoders already have the capability of storing their consist status as a CV, it would be a relatively simple software change to implement an automatic master/slave setting.

The best part is that it would be completely seamless from the operator's point of view, and totally backward compatible.  The master decoder would function normally, and in fact could (as you pointed out) be a decoder without the master/slave capability.  Any decoder in the consist not capable of being assigned slave status would also function normally, as well or as poorly as ever.  Slave capable decoders would automatically react as smoothly as possible.

Or you could just buy a RailPro

I'm just being a S#*t. LOL

Just spit balling here, but would you not end up with the type of effect that the Faller Car systems have with the infared sensors where the trailing car runs up on the slower, then backs off and then runs up, and then backs off, and then runs up...  So the smart engine would be, for lack of better terms, chugging back and forth between the dumb engines?

Not a criticism Benny, cause I love where you are going with this.  I love consists, and I really liked (as I'm sure you did) the RP handling of the shared load.

Here's a thought;  how about make them all smart engines using bluetooth?  We don't need any range of communication so BT would be fine (5 feet would be a huge consist and BT has a 20-30 ft range).  So could an add-on BT chip be added to our existing loco decoders to make them smart?  From a size standpoint, a bluetooth chip can be very small.  I will admit I have no idea of how BT works so I don't know if they can be stand alone smart...however...

On another post Benny, you talked about how smartphone throttles are the next wave (which I agreed).  Those are all BT compatible.  What if we put a BT transmitter in the engines that monitors the load, that signal could be transmitted to the smart throttle (If that term catches on, you heard it here first), where the smart throttle could adjust the speeds of all the engines in the consist.  Whoa...that sounds like it might be too easy.  Our existing decoders wouldn't even know it was there because the load sensor would be on the motor, not the decoder.  The decoders would just think "man! pick a speed already".  You would definitely need to be using 128 speed steps to allow for the minute adjustments in speed.  

And to make the above work even better, you would still speed match your engines, but you would only need to get them "close enough".  And even a speed match pair of engines might not be speed matched on a grade due to one motor being stronger then another, but the BT smart throttle would handle that.

Open source collaboration rocks!!!

Benny, add that to your wLAN system that I know you are working on right now.  If it works, I only want 50% of the credit, if not...Benny who?

Jeff.

Of course the downside is

you would have to be running a JMRI setup, but I feel that is the direction the hobby needs to, and will go (needs to be more plug and play though for the masses to accept it).

Jeff

...

JMRI is about as Plug and Play as you can get...and yes, that is the way things will go.

It is quite obvious that the Best solution will ultimately be a new Decoder, one with 2-Way Communcation capabilities like Railpro's decoder, and Zimo's decoder also has similar ability.  Our present DCC decoders are one way devices; once they are Two way, I suppose we could go as far as to kick out the command station altogether, or upgrade the PR-3 to the point that it IS the command station/ wireless signal generator.  The Gen-2 Decoder will be nice, indeed.

But that leaves us with a fleet of Locomotives all carrying Gen-1 Decoders - and even after we start bringing Gen-2 Decoders online, the Best System will still be compatible with the Gen-1 line.

So I got to thinking it would be really novel if we had a minimal upgrade that would make these units easy to consist.  Ken, you got it right with how you termed it, Slaving these Gen-1 units to Gen-2 Masters, though it would perhaps be just as easy to go the other way too.

This solution would be purely electromechanical, which essentially means it requires nothing more than the input and output to the motor and a current; no code would be necessary.  hence, we could throw this little device in the motor circuit, and with no further work we have a rudimentary means of balancing power, even if it is perhaps a little archaic.

Quite obviously, we could simply keep the speed tables updated, which does the job well, and it gets much easier with JMRI!

Automatic speed tables!

How about this..  If we had a way for JMRI/Decoder Pro to read the motor current in real time, then we could have one reference locomotive, and have Decoder Pro automatically develop a speed table in another model to match.  For example, consist the two (subject and reference) and then run them through the speed steps.  By reading the motor current it should be possible (perhaps after a few runs) to come up with a speed table which matches the reference.

In fact, you could do away with the reference locomotive and the need for reading the motor current if you built a locomotive dynamometer.  Put the loco on the dyno and run it through the speed steps.  Adjust the speed table so that the speed curve is whatever you like.  It would be just like tuning a car or a motor on a dyno the way the automotive guys do.  And with the right hardware/software, it could be done right now without ANY modification to the DCC standard.  It wouldn't be automatic, but it would sure simplify speed matching.

...

This is why I host these discussions - Ken, that's downright brilliant!!

Brilliant is what I do

I try

Some more thoughts on the dyno idea.  For starters, I don't think it would be very hard to build.  I'm not an engineer (well, I am, but not the kind we need in this case), but it seems to me that all you'd need would be something like a stepper motor driven by the wheels (is that a rotary encoder?).  I have no idea how the computer interface would be built, or how the software would be written, but I don't think either one should be all that difficult.  Since the point would be just to measure speed, all you'd need would be a single roller under one wheel, and it could be built as a replacement for one of the commercial rollers.  A rubber tire might be beneficial to ensure accurate speed readings (no slipping).  Ideally, the hardware should be inexpensive - less than $20?

Once you have the hardware figured out, the software would have to be able to act as a throttle, comparing actual speed to speed steps.  It should then be able to act as a programmer (presumably using Ops mode programming) to adjust as many points on the speed curve as possible.  Ideally, it should be possible to put the engine on the rollers, turn the program on, and let it run until it's achieved the best results possible.

Modelers or clubs could of course develop their own ideal speed curves, or we could all agree on an industry standard.  Perhaps if all the manufacturers had a good way of making an engine match a desired curve, they could work together to make all new models work together.  It would also be a relatively simple task to reprogram an engine to work with a club's standard speed curve, assuming they made the curve available to anyone who might bring an engine to their layout.  Same with you coming to visit my layout, etc.

I can see at least one potential problem.  Models do not run at the same speed for a given motor voltage when they are cold as when they're warm.  It would probably be necessary to warm an engine up prior to programming, and of course to break it in as well.  If an engine were to suddenly quit playing well with others, it might be a good indication that the model is in need of service or repair.

One other thing.  Speed matching isn't just for running engines together in a consist.  There are other advantages.  One is that you could design your speed curve so that a scale on the knob could accurately read scale miles per hour, or otherwise know what the actual speed is.  Another, perhaps more important, is that pushers on the rear of a train MUST work well with the head end power.  If they're too slow, you run the risk of pulling the train off the track, and if they're too fast they are trying to push the train up off the track.  Both are recipes for derailments.  If all the engines run at the same speed, you can consist the pushers and keep the train running smoothly.

...

Ken,

What you are looking at is called a closed loop servo system used on CNC machines. I'm afraid to tell you, but it would cost a little more than $20. It is a good idea though, just costly.

Bernd

Why?

Not trying to be difficult or argumentative, but why would it cost so much?  It seems to me that the hardware wouldn't be that complicated (just a stepper motor or something which generates regular pulses as it rotates) and the electronics would only be whatever is needed to convert those pulses into something a computer could read.  Everything else should be done in software, I assume.

Like I said, I'm not the expert here, so maybe I'm missing something obvious.  Unlike CNC applications, we don't really need to know the angular position of the dyno rotor.  The only thing we need to know is the speed in real time.  Even a single pulse per rotation could work, and it could even be done on an existing roller by adding a white stripe and light sensors, much like some companies have optical chuff sensors on their steam locos.

If I had the requisite knowledge, I'd build it just to see how well it works.  I guess what's needed are someone with knowledge of how to build a computer interface, and a programmer who can write the software to do the needed calculations and CV programming.

So nobody likes the Bluetooth idea?

I'm guessing that since nobody commented on the Bluetooth idea, nobody thought it was worth consideration.

Oh well, just a thought, and I by no means have the required knowledge to determine if it was a good idea.

Jeff

Servo Mechanisms

Ken,

The best I can do is point you to some reading of how a system like that works. Start here: http://en.wikipedia.org/wiki/Servo_motor  

A rotary encoder is used also for speed control on a servo motor. A CNC machine uses a combination of rotary and linear transducers to figure out were all the moving parts are and how fast to move them. A single stripe on a wheel will not cut it for speed control. That would be like having only 8 steps on your Digitrax throttle instead of 256 steps. The more steps the finer the control.

I could tell you all about how this works but would take way to long to type in. May I suggest some investigation on the net for answers.

Regards,

Bernd

So...

I am no expert, but it sounds like You do not need to measure any voltage, resistance, or amperage to do this.

It sounds like You want a timing circuit. Time and distance will give You speed, so if the loco turns a wheel large enough to to have optical sensor marks on it, You could record the time it takes to make a rotation. Feed that data real time to a speed program, and get the speed of the setting. You may want to take an  average of 500, to 1000, samples at each speed setting, as to help remove minor discrepancy in the mechanism.

Do this for all 128 steps, and convert it to scale speed, You will have the speed table for that loco. Once you have a speed table for all the loco's in Your fleet, You then could make Your Standard Speed Table for your layout. Upload the Standard Speed Table to all Your loco's, and consist away.

A new loco just has to be run to get it's speed table. and then be compared to the Master, to see if it can use the Master Table, or the Master would have to be reworked.

So it looks like this to Me:

     1. You need a program to collect speed data, and build a speed table for a loco.

   2. A program to analyze speed table data, from all loco's, and build a Master Speed Table.

    3. A program to load the Master Speed Table data to a loco. 

        (all ready out there, may just have to have a File Translator)

     4. A program to analyze a mew loco speed table to see if it can use the Master Speed Table.

This seems to be a better way of speed matching Your fleet. Trying to use a circuit to balance current, amps, volts, and or wattage, just has to many variables, that would drive One nuts trying to over come. Then You have gear ratios of the different drive mechanism. So even if You have the motors getting the same current, the mechanisms may not output the same speeds. This leads Me to belivie that a better way of building a Loco's speed table, rather than by Eye, should give the best bang for the buck.

Now I could be wrong....

A shaft encoder

relative to current available... huh???

So how does this thing know what "current is available" as a result of the lead or trailing engine versus the current available as a result of the engine on the next track over??? Back EMF works relative to itself-- using an onboard sense resistor to measure how much current the loco itself is using and then boosting or retarding the motor voltage to itself accordingly, according to some function in the CPU part of the onboard DCC decoder..

John

You don't want a stepper

You don't want a stepper motor. That's the wrong device for the job. Instead you want a current sense circuit which develops an "error correcting" feedback quantity (voltage / shaft-encoder pulses / whatever) which is fed back into the motor control circuitry at some point (probably at the input) and used to modulate (adjust) the speed of the motor accordingly via some type of hysteresis function.

John

...

Silverbackman, Bluetooth was something I first hacked into back around 2007 on the Atlas forum, it was a lively discussion...aha!

I think it could very well be a useful device, but it's in direct competition with the other RC technologies. it could have a very prominent place if it were to become the "CPU" inside the locomotive.

But then we come to the next question, why use bluetooth if we can go one step better and put in a standalone wireless chip in the locomotive?  I suppose the answer all comes down to the communication times between devices.

...

And to the debate ensues...which is a better input/output for the dynometer, an electrical load or a mechanical load?

I suppose at this point someone out there will just build one...

 Greg, I think you have a good point, but this test is 3-variable.  Speed alone is one issue, but speed under a load is a second issue.  A unit may perform one way alone, but once you put a load on it, this changes things, particularly depending on gearing and operational characteristics.

Ken, it would be nice to have that real scale speed indicator.

Bernd, your mechanical expertise and machining knowledge is most appreciated!  Very good points indeed!

John...that's the sort of device I was thinking about, only in the motor circuit under the locomotive hood...but if the speed tables where more accurate [in three variables, as opposed to two variables], it would be a non-issue...perhaps?  but then we're no longer looking at 128 step speed tables, we're looking at 256 step speed vector tables...where every one step in the x axis is then gauged 128 steps in the z axis...

Now I wish I had paid better attention in vector Calc!!

...

Benny,

Here's a chip that should be usable.  http://www.cypress.com/?id=2425

Bernd

nice chip

Yes, that does look like a useful chip. 

If you were going to solve this problem "the right way" you would want positive closed-loop feedback on the loco speed / speed of the motor. The best way to do that would be with a shaft encoder-- probably optical and certainly high resolution. Then to use the output of the shaft encoder as the error-correction feedback element to the motor. You would still need to coordinate / communicate between the several locos in the consist. However, it'd now be a lot easier because there is something "universal" and "constant" which can be communicated-- the speed (revolutions per second, or whatever). Presumably we're putting the same reference into each engine. Then it doesn't matter how much or how little current the motor draws, only the current pulse-count per second matters. Which should be the same going up a hill, down a hill or straight and level. It doesn't account for wheel slippage, but wheel slippage can be detected and (attempted) corrected for, since it would be a spike in the pulse count while the wheel is Spinning faster. I don't see how any backwards-compatible add-on module could really be applied. You would need access to the inerrnals of the DCC Decoder and its CPU.

John

Why so many problems with speed matching?

There are several problem with the current decoder BEMF based speed control systems which cause instability including the accuracy of the BMEF voltage measurement due to component tolerances and uPC timing and analogue to digital converter (ADC) accuracy and precision. Motor and drive variations also add significantly to this inaccuracy. And although BEMF is primarily a function of speed in practical systems / circuits it is also a function of load. For true balancing, as done other motor balancing systems like real 1:1 locomotive consists, the software needs to "model" the characteristics of each locomotive motor over both speed and load ranges (e.g., as noted three dimensional tables) and / or the systems need better feedback from devices such as encoders. Therefore, with the current decoders and speed tables the best you will ever do is a relative match under a limited set of load conditions.

Now current decoders with adequate software can do a better job of measuring motor rpm – difficult but doable as with some QSI decoders which include higher speed, higher resolution ADCs and crystal oscillators. But the dynamometer needed to develop advanced speed tables will also have to perform like a real dynamometer and measure the force (load) and speed. There are several commercially available devices for setting / measuring speed and force, such as hysteresis brakes (http://en.wikipedia.org/wiki/Dynamometer), but they definitely run more than $20. I have cobbled together a DC motor, used as a generator load, and an encoder sets for testing motors, but the measurement / control circuits are not simple and controlling the load on the motor is a real pain. Plus I had two programmers to deal with the software. In the long run to meet testing specifications I ended up purchasing hysteresis brakes with encoders and programmable controllers for motor testing. And for the test fixture your dyno will have to be linked to all locomotive drivers, so you will need a different fixture for each locomotive configuration. Of course you might be able to build the dyno in a model dyno car, but then you will need a duplex RF system to manage load regulation and data telemetry.

In future decoders it would be simpler to add a cheep encoder to the motor shaft for direct feedback of the rpm to the uPC on the decoder. And since most uPC's on decoders have unused inputs, all it would take is a high contrast mark(s) on the flywheel and an optical detector (e.g., LED and Photo Transistor) for a total cost of under $1 per locomotive. Think of when you could actually work on a car using a timing light. I have used this type of detector on commercial products and effectively on Large Scale locomotives. Then for speed matching the controller could send specific speed settings to all locomotives in a consist and the decoder feedback systems would have to ensure that the locomotive maintain that specific speed. But this is not realistic operation.

Realistically, as the load on a locomotive varies due to curves, terrain, and car loads there are variations in the operation of the locomotive. Several decoders manufacturers, specifically for good sound decoders, have worked hard to develop decoders that respond somewhat realistically to load conditions. I could turn them off, but I like how the sounds and operation of my BLI N&W Js and bit Shay change under varying load conditions. For a decoder with these features, matching for all speed and load ranges will require the system to transmit the lead locomotive speed to all other locomotives in the consist. Now RP-9.3.1 Electrical Specifications for DCC Decoder Transmission does allow for decoder information to be passed back to a controller; however, the DCC data rate may not be adequate to keep up with changes in the speed of the one lead locomotive let alone several operating on a layout. Another option would be to provide direct communication between all locomotives in a consist. RP-9.1.1 Electrical Interface & Wire Color Code includes a General Input / Output bus which could be used for passing speed information via wired connections or with optical or RF system adapters.

Given the above discussion and the knowledge that some of my carefully “speed matched” locomotives still cause derailments or pull their couplers apart, find that current decoder speed matching capabilities will for some locomotives continue to cause us a great deal of frustration in the foreseeable future. Now all we can hope for is for decoder manufacturers to read these postings and begin to design some of these features into their future offerings.

Ken K

WOW Ken

That was quite some explanation. I think I heard a few circuit breakers pop on the guys that use DCC.

Sounds like one would be better off tweaking the engines mechanically to get them to run together. But of course the electrical guys won't like that. Oh well.

Bernd

Your locos aren't really carefully speed matched...

Given the above discussion and the knowledge that some of my carefully “speed matched” locomotives still cause derailments or pull their couplers apart

That's because your locos aren't really "carefully speed matched"-- they are of course, to whatever the degree that you're able to adjust them, but there is no feedback loop to ensure that they are actually running at the speed you set them for. Thus, due to mechanical differences and/or slight local variations in electrical pickup / efficiency / blah blah blah, they drift a little from the desired speed. How much and how bad depends on your exact conditions. The situation is pretty much analogous to riding down a straight road and carefully gauging how far your car drifts to the left or to the right, and then "tying the steering wheel" so that the car will "roll straight" on its own. Then getting out of the car, sticking a brick on the accelerator and expecting to see the thing roll straight down the middle of the roadway. The odds of that actually happening without drifting to one side or the other are very slim. However, if you had some way of measuring the drift-- perhaps by judging the distance from the white lines painted on the left and right, you could devise a mechanism which could do a much better job of it through closed-loop feedback. Certainly selecting components that are mechanically-matched to begin with is not a bad idea, in fact it is a great way to get started. But adding a closed-loop error-correction feedback mechanism is generally a superior method. (Of course, I suppose you could add a closed-loop mechanism that worked badly-- but apart from that...)

John

...

This was the general idea, John, a closed loop system that is so basic that it would be inexpensive enough to be thrown into the motor circuit on a decoder without much thought, with the idea being that the point in the curve where the current draw is the least [but not zero], the motor is working at maximum efficiency if in tandem with a second unit.  Something as simple as a bridge, or a transistor circuit, with an in, and out, and a reference pin.  But of course that would be too complex versus simply using software to do it.

The idea is a band aide to get from one point where the decoders do not have this internal ability, and the next where decoders by default do.

As soon as software becomes part of the game, though, it's curtains for this thought because at that point one had might as well just throw in a new decoder with direct feedback programming already onboard.

But anyhow, fun talk.