I'm programming a locomotive that when reset to defaults (short address 3), it works fine. However, when I give it a long address it always runs in the same direction, regardless of setting forward or reverse. Checked cv29 (value of 38), fiddled with a few other values with no change. I'm flummoxed.
You need to provide the manufacturer, approximate date of manufacture, and locomotive type, and the particular decoder model and maker.
To my knowledge there is nothing in the general DCC standard that would enable this behavior; the decoder alone sets the DC polarity to the motor that determines its rotation. If the code 'set' to determine this is "per spec" I think you have a specific decoder fault -- the interesting thing then perhaps being whether it's a hardware problem or firmware...
rfnpspatcherinrichmondover I'm programming a locomotive that when reset to defaults (short address 3), it works fine. However, when I give it a long address it always runs in the same direction, regardless of setting forward or reverse. Checked cv29 (value of 38), fiddled with a few other values with no change. I'm flummoxed.
Rich
Alton Junction
Try disabling DC in CV29. Try 34 as a value and try again.
After doing the factory reset, does the problem occur after you just add the long address or have you made other CV changes as well. I would test the locomotive after each CV change. That would give you an idea as to which change is causing the directional problem.
Another possible problem is if the long address has ever been assigned to an MU. If it has, the loco will take its direction from the lead loco in the consist.
It would help to know the brand and type of decoder as well as the type of DCC command station.
It is a curious problem. The usual suspects would seem to be CV29 and even CV19.
How many throttles are you using? Could be an addressing problem.
Tell us more.
Lastspikemike The "reverse direction" value in CV29 (adding 1 to the existing value) has nothing do with forward or reverse signals from the throttle. That change to CV29 just reverses the polarity output to the motor and connected lighting functions. It makes forward into reverse or vice versa. CV29 is a red herring here. It probably isn't relevant but my MRC Tech 6 won't drive some dual mode decoders in reverse direction when delivering power in its DC output mode. The direction switch on the powerpack has no effect. I've always thought that's a curious phenomenon. By analogy then maybe your dual mode decoder is seeing a DC signal as if the throttle is sending a DC power signal to address 00? Disabling DC mode in your decoder might be worth experimenting with.
The "reverse direction" value in CV29 (adding 1 to the existing value) has nothing do with forward or reverse signals from the throttle. That change to CV29 just reverses the polarity output to the motor and connected lighting functions. It makes forward into reverse or vice versa.
CV29 is a red herring here.
It probably isn't relevant but my MRC Tech 6 won't drive some dual mode decoders in reverse direction when delivering power in its DC output mode. The direction switch on the powerpack has no effect. I've always thought that's a curious phenomenon.
By analogy then maybe your dual mode decoder is seeing a DC signal as if the throttle is sending a DC power signal to address 00?
Disabling DC mode in your decoder might be worth experimenting with.
Adding 1 to CV29 if it already has an odd number value is going to have a ripple effect. If the 0 bit already has a value of 1, it will flip to 0 but also add 1 to the number 1 bit which could affect the number 2 bit and so on. To change the direction, you add 1 if it has an even number and subtract 1 if it has an odd number.
Lastspikemike Thanks. Another mysterious aspect of CV changing clarified. I use the little charts and deduced erroneously.
Thanks. Another mysterious aspect of CV changing clarified.
I use the little charts and deduced erroneously.
Having been a mainframe programmer for most of my working life, I had to learn the nuances of both binary and hexadecimal arithmetic. That became less important over the years, but it was still a good thing to know.
One convention of mainframe programming that seems to have carried over to decoder programming is the method of addressing bits and bytes. It is done as a displacement which means the first bit in a byte (the right most one as you observe the binary number) has a displacement of zero. The second bit has a displacement of 1, the third bit has a displacement of 2, and so one for all 8 bits of the byte.
It seems that each bit in CV29 affects a different function, so adding a number to one bit can change the value of the next bit to the left which can change the value of the next bit to the left and so on. Bit 0 is the one that controls direction and that is the only one you want changed when reversing direction. That's why you add 1 to an even number and subtract 1 from an odd number.
The OP may have a Broadway Limited Paragon 3 decoder. I've had a similar issue with about a third of the P3s installed in my recent BLI locos. In one case after replacing the decoder twice I gave up and installed an ESU decoder. BLI service tried their best but the silly thing still would not cooperate.
After a reset (a physical hard reset using the on-board, inaccessable rubber button) the engine would perform fine but any attempt at changing the address would scramble its poor little brain. The result would be limited, sporadic movement in forward and in reverse the engine would run at top speed, also moving forward forward with no control.
We'll have to wait to hear back from the RF&P Dispatcher in Richmond.
Over — Out...
Good Luck, Ed
The more I read about issues with BLI locomotives, the less impressed I am with their quality control. These issues are inexcusable in high end locos. It's one thing to produce an occasional lemon, but there shouldn't be problems that are so common.
John-NYBW The more I read about issues with BLI locomotives, the less impressed I am with their quality control. These issues are inexcusable in high end locos. It's one thing to produce an occasional lemon, but there shouldn't be problems that are so common.
John-NYBW Lastspikemike Thanks. Another mysterious aspect of CV changing clarified. I use the little charts and deduced erroneously. Having been a mainframe programmer for most of my working life, I had to learn the nuances of both binary and hexadecimal arithmetic. That became less important over the years, but it was still a good thing to know. One convention of mainframe programming that seems to have carried over to decoder programming is the method of addressing bits and bytes. It is done as a displacement which means the first bit in a byte (the right most one as you observe the binary number) has a displacement of zero. The second bit has a displacement of 1, the third bit has a displacement of 2, and so one for all 8 bits of the byte. It seems that each bit in CV29 affects a different function, so adding a number to one bit can change the value of the next bit to the left which can change the value of the next bit to the left and so on. Bit 0 is the one that controls direction and that is the only one you want changed when reversing direction. That's why you add 1 to an even number and subtract 1 from an odd number.
Early in my career, I was a programmer and then a systems analyst. Back in the day, you needed to understand bits, bytes, binary and hexadecimal arithmetic.
Let's delve into this a little more.
There are 8 bits in CV29 (zero through seven). The decimal value of each bit is an even number except for the decimal value of bit 0 which is an odd number of 1.
For example, the decimal value of bit 1 is 2, and the decimal value of each succeeding bit is double the decimal value of the preceding bit. So, the total decimal value of CV29 can range from 1 to 255. But, in practical application, the total value of CV29 will not exceed 63 because bits 6 and 7 are usually reserved.
The following link is to a calculator for determing the proper value of CV29.
http://www.2mm.org.uk/articles/cv29%20calculator.htm
A typical value that I use for CV29 is 34 to program forward direction (0), 28/128 speed steps (2) and the long address (32). If I want to change direction (such as in a consist), I add 1 for a value of 35. As John-NYBW pointed out, the problem with blindly adding 1 to the value of CV29 to program reverse direction is that it affects other functions in CV29. For example, adding 1 to CV29 in this example results in a total value of 36 which reverses direction but also enables DC, even if you didn't intend to, and sets the speed steps to 14 instead of 28/128.
I had a practical application of CV29 when I added a pair of P1K C-liners to the roster which I wanted to run as an AA set. When I want to permanently pair locos together, I just assign both of them the address of the lead unit rather than create unique addresses for both and MU them. This was the first time I paired A units together so one would have to run backwards if I didn't want to run them elephant style. That meant reversiing bit 0 in CV29. I put a LokSound in the lead unit and a LokPilot in the trail unit. When I put them on the programming track and read the value for CV29, it was 50 for both units so I had to add 1 to the trail unit for a value of 51. A value of 50 in decimal converts to a binary number of 110010. Working from right to left, we have a 1s in the columns for 2, 16, and 32 which added together yield 50. Adding 1 gives a decimal value of 51 which converts to binary 110011. Had the default value been 51, I would have had to subtract 1 in order to reverse the direction without changing the value for other functions. If I added 1 to binary 110011, it would have converted to binary 110100 so not only would I have changed the direction, I would have changed the functions in bits 1 and 2 which are the 2nd and 3rd bits from the right.
I know I don't need to explain this to Rich but it's a primer for those who either were never taught binary arithmetic or had it so long ago they had forgotten.
wrench567 Try disabling DC in CV29. Try 34 as a value and try again.
I just went back through the thread and this sounds like the most likely answer. Analog mode is controlled by the third bit from the right which is the fours digit in a binary number. You want that digit set to 0. A decimal number of 38 converts to binary 100110. You want the third digit from the right set to 0 so entering a decimal value of 34 in CV29 sets the byte to a binary value of 100010.
Locos running in analog mode have direction determined by track polarity as opposed to engine direction. I've noticed that when I get a DC engine. Before installing a decoder, I first test it in analog mode by setting the address to 0. It moves in the direction dictated by track polarity. It doesn't matter which way the engine is facing.
Speed steps are set incorrectly. You have to set the speed steps 14/28/127 at the command station so it knows how to send the bits. Also make sure CV29 is set correctly and you can read from the decoder on the programming track (to make sure it's a viable decoder)
Don - Specializing in layout DC->DCC conversions
Modeling C&O transition era and steel industries There's Nothing Like Big Steam!
The problem is that people are confusing bitwise adds with decimal adds, as if the purpose was to increment or decrement an actual representation of a number.
Most of these multiple CVs are in the form of positional flags, like the sliders in DIP switches. The idea of 'adding 1' to change a particular value 'from zero to one' as if you were sliding a DIP switch up is attractive as a simple analogy, but as noted if you try to 'add' that 1 positionally in binary you get carries, the risk of two's-complement negative numbers, etc. that very few people trying to program CVs want to know about.
What they need to realize is that when they add or subtract numbers that are 'powers of two' to the decimal representation of a CV, they are flipping just one specific corresponding bit in the binary representation... just that one DIP switch controlling a particular function. That's the magic in going between '34' and '38', for instance -- you aren't so much "adding four to a number" as you are changing ONE positional digit in the binary byte without changing, or shifting, or affecting or whatever any other digit in it. And now you understand why just changing that one digit is the purpose of the exercise.
The way to deal with CV29 is to read its value on the programming track. No guess work that way.
Just use a CV29 calculator, like this one ....
Mark.
¡ uʍop ǝpısdn sı ǝɹnʇɐuƃıs ʎɯ 'dlǝɥ
The OP left the building!
To be honest. I don't have any decoder with nothing but 34 in CV29.
Pete.
Overmod The problem is that people are confusing bitwise adds with decimal adds, as if the purpose was to increment or decrement an actual representation of a number. Most of these multiple CVs are in the form of positional flags, like the sliders in DIP switches. The idea of 'adding 1' to change a particular value 'from zero to one' as if you were sliding a DIP switch up is attractive as a simple analogy, but as noted if you try to 'add' that 1 positionally in binary you get carries, the risk of two's-complement negative numbers, etc. that very few people trying to program CVs want to know about. What they need to realize is that when they add or subtract numbers that are 'powers of two' to the decimal representation of a CV, they are flipping just one specific corresponding bit in the binary representation... just that one DIP switch controlling a particular function. That's the magic in going between '34' and '38', for instance -- you aren't so much "adding four to a number" as you are changing ONE positional digit in the binary byte without changing, or shifting, or affecting or whatever any other digit in it. And now you understand why just changing that one digit is the purpose of the exercise.
It sounds like most/all systems work the way my Lenz system does. You enter a decimal number into a CV and the programming converts it to a binary number that sets the individual bits. To know which bits a decimal number is going turn on or off it helps to understand how binary works. A binary calculator is a good tool but working in binary became second nature to me and I actually enjoy doing the number conversions to determine what value to plug into a particular CV. It makes me feel I'm more in control.
Lastspikemike Maybe I wasn't just changing a CV value directly. Maybe I was just instructing my DCC system to change the CV value.
Maybe I wasn't just changing a CV value directly. Maybe I was just instructing my DCC system to change the CV value.
Lastspikemike When I added 1 or deducted 1 the DCC system made the change to the correct bit.
When I added 1 or deducted 1 the DCC system made the change to the correct bit.
Most likely, adding 1 to the CV29 value is only going to affect the directional bit (the 0 bit) because the default value for that bit is probably going to be 0. However, if CV29 has been modified previously, adding 1 could cause a ripple effect. It's best to check the value of CV29 first and make sure it is an even number before adding 1 to it.
If the OP comes back, I'd ask him to do the factory reset, but then change to a short address (like last two numbers of the engine) and see if that works. If so, the problem isn't changing the address per se, it's a problem when trying to do the long/extended address.
On the old Digitrax Zephyr I use for break-in runs on my test track and programming, you just have to read the long address (0003) and then put in what you want and hit the programming button and the system calculates what to put in the extended address CVs and makes the changes.
If he's using a system where he has to calculate and enter each CV piecemeal to get the long address, I suspect that's where something is being entered in the wrong place or something.
When I first clicked on to this thread a few days ago I was expecting to see something like this.
Image courtesy of NYCSHSBlogger
TF
Track fiddlerWhen I first clicked on to this thread a few days ago I was expecting to see something like this.
Center cab diesels are the best!
-Kevin
Living the dream.
Just to be clear, binary numbers are simply a representation of what an electronic device stores in its memory. It doesn't actually store 0s and 1s. It has bits which have either positive or negative polarity. We use 0s and 1s to indicate which. Most computers have 8 bits to a byte. I've heard of systems that had 6 bit bytes but I never worked on one.
Early computers had magnetic rings for each bit and these rings were charged by vertical and horizontal wires running through them which would charge them positively or negatively.
Computer Memory - History, Timeline and More (thoughtco.com)
Eventually this type of memory was replaced with chips which became smaller and smaller and thus allowed greater and greater memory. When I started in the computer field in 1977, I worked on an IBM 370 mainframe with 512K of memory. Just 7 years later, I purchased one of the early MacIntoshes which also had 512K memory. Computer memory increased exponentially over the decades, being measured in megabytes, gigabytes, and terabytes, each measurement being a 1000 fold more powerul than the previous (actually 1024 times more powerful). It still comes down to a matter of bits and bytes and we represent those bits and bytes with binary numbers because it's easier for humans to think in those terms. Hexadecimal was implemented to convert 4 binary digit to a single hexadecimal digit. A byte can thus be represented by two hexadecimal digits.
If you have read this far without falling asleep, I hope this little primer has been helpful to you in understanding the basics of how electronic devices process information.
John-NYBW If you have read this far without falling asleep, I hope this little primer has been helpful to you in understanding the basics of how electronic devices process information.
I started out in "data processing" in 1965, right out of college, and worked on the IBM 407 Accounting Machine and the IBM Sorting Machine. Loved those punch cards. And, let's not forget the 1401 magnetic tape machine. By 1969, we were working on the IBM System 360 with those iHop pancake storage devices.
I find it amazing that computing devices today still use the binary number system.
richhotrain John-NYBW If you have read this far without falling asleep, I hope this little primer has been helpful to you in understanding the basics of how electronic devices process information. John, it might be only you and me still awake, but I enjoyed that little trip down memory lane. I started out in "data processing" in 1965, right out of college, and worked on the IBM 407 Accounting Machine and the IBM Sorting Machine. Loved those punch cards. And, let's not forget the 1401 magnetic tape machine. By 1969, we were working on the IBM System 360 with those iHop pancake storage devices. I find it amazing that computing devices today still use the binary number system. Rich
John, it might be only you and me still awake, but I enjoyed that little trip down memory lane.
As the saying goes, "If it ain't broke, don't fix it.". The binary system has served the industry well and I don't know what we would replace it with.
I learned programming at a technical school and we had a hand me down Univac 9200 computer with 8K of memory. This was in 1976. I'm sure it was obsolete then. We had to learn stone age programming techniques so our programs wouldn't exceed the available memory. The only input device was the card reader so we inserted our programs into a card compiler. At some point, we obtained an IBM 360 that had 64K of memory and we thought that was all anybody would need. It also had a disk drive the size of a washing machine.
When I got my first job as a programmer, we were still punching out programs into cards. We would then have one of our clerical people carry them down to the computer room and maybe an hour or two later we would get back the results. If we were lucky, we would get two runs a day. We spent a lot of time desk checking. It was about a year later we got terminals and were our to submit our jobs ourselves and get immediate feedback. Needless to say that greatly improved productivity. I left that shop but came back to work there in the 1990s and believe it or not, we still had one application that read punched cards. I had to show one of our recent college graduates how to punch his JCL into a card deck to run a test.
I remember learning to read core dumps as they were still called and it was a necessary skill and one that became a lost art. I doubt I would even remember how to begin to do it now. With the way memory increased exponentially over the years, printing a core dump could kill a good sized tree.
By the time I retired, I was a dinosaur. Our shop had migrated to largely distributive processing and there was much less emphasis on the mainframe applications. We still had enough critical legacy systems to keep me in a job until I decided to call it quits. A few years later, they outsourced those legacy systems and got rid of their mainframe.
One other thing most people don't realize is how much heat a mainframe computer generated. In the early days of vacuum tubes, there would be one large room for the mainframe and two more on either side of the computer room to run the air conditioners required to cool it. Even after circuit boards and chips replaced vacuum tubes, mainframes ran in special rooms with raised floors for the air condtioning ducts required.