Hi All, While I have been watching the boards for DCC++ for a while and a software developer by trade (so know a fair bit - which may be my downfall), I've only just got my first Mega + Rev3 shield up and running this weekend. I also have an EM13 decoder fitted to a Kato engine. DCC++ code is at 1.2.1. I can read (and I think I can write) the decoder from JMRI (DecoderPro) as well as the DCC++ Controller "Processing" sketch - and I can also talk to it with a serial package from node.js (see - geek programmer). I can also send commands from the Arduino serial monitor. The LEDs on the boards seem to behave correctly (and also the <D> diagnostic appears to be working as expected). The loco does jig around when reading any of the CVs (e.g. in Gregg's Controller in Programming mode and reading the Engine Address - which I believe does about 3 reads - the loco engine does physically respond by moving the motor slightly). However.... I only have the programming track connected right now (I could switch it over to the main output) but I am not sure I have everything "right". I had expected that I could still send throttle commands to check that the loco was behaving correctly but - even just using the Arduino serial monitor - but the loco does not respond and the software does not return the documented acknowledgement. I have noticed (if the track power is already on and I hook up DecoderPro) that the loco does a quick little back and forth run on the track as things are reset (I can replicate this in node.js by sending the <1> and never sending the <0> command). So, it does feel like everything is "working" and there are no burnouts (yes, I did cut the VIN track on the Rev3 and tested there was no connection with a meter before assembly and before powering it up). Have I got something wrong ? Is the doco wrong for the throttle command ? Does the throttle even work on the programming track ? (and JMRI is a bit vague about how it's throttle window is supposed to work - which is why I switched over to using serial and node.js - just so I felt I was closer to the code). Having got this far without any hitches it seems a bit strange (it only took me about 60 minutes to solder up some track feeders to a small piece of Kato track, plug the boards together, install the EM13, load the software, and get the basics done). So I am assuming it is some knowledge I am lacking at this point rather than it being an issue with either the hardware or the DCC++ codebase (or even JMRI). [Also sorry if this was answered somewhere else, but I don't find the search facility on the board very intuitive in refining my search] Regards, Gary
Well... here is an update..... I am guessing (and happy to be told otherwise) that the Programming Track doesn't support throttle (<t 0 addr speed direction> - even though the doco says that register 0 is for programming). I connected my short track to the Main and sent a <t 1 3 5 1> (my train address is currently 3) sends it off happily and a <t 1 3 5 0> brings it back. However, JMRI is still stumping me. The throttle commands (sent manually as I am doing in the serial window - without the <>) do not seem to work (even though I can get other stats out of the DCC+ base station) and the throttle gui component in JMRI is really confusing. Regards, Gary
I don't use JMRI, but my understanding is that the difference between the registers is that a command sent to register '0' is passed to the track only once, then that register is cleared. Commands sent to the other registers (the default max I believe is 12) are repeatedly sent to the track sequentially and not cleared/changed until another command overwrites any particular register. Therefore register 0 is used on either track, for programming and accessory commands (turnouts etc), so those only get the one command sent to the track, whereas the other registers are used (I presume only on the Main track) for throttle commands which get repeatedly sent, so should a loco momentarily lose connection and reset, it can reconnect and continue at the same speed. This is why you can get strange effects if you send a throttle command to a loco using one register no, then send a different speed command to the same loco but with a different register no. The loco rapidly alternates between the two different speeds.... The programming track does not get throttle commands, regardless of the register used. Jim
Thanks Jim... I started thinking I was going crazy. I am putting this together slowly so I am sure I understand all the ins and outs and had been only working on the Programming track. Because I was sure it should be working I switched the track I was using over to the Main track and, surprise, it was all working. But what you have said about Reg 0 being cleared makes sense to a certain degree. In any case, I also downloaded RocRail and can control the loco with that on the Main track without any issues. I'll probably go back to JMRI and have another go - now that I other methods seem to be working. Regards, Gary [Then it will be on to occupancy detection and turnout control]
In JMRI, check the preference that DCC++ is selected for the primary command station and programming. and not some other device for these is selected.
UPDATE: I had checked that the DCC++ device was the selected one - and even checked again tonight (after I managed to get the serial monitor, RocRail and my own node.js application running the loco) and it was still not working. So, I decided to create a brand new layout in JMRI and connect to DCC++ again (also again checking I was using DCC++ and not "internal") and lo and behold, JMRI decided to work! I even ran a Jython script (similar to what I had written in node.js) to automatically run the train. So, I don't know what was wrong with the original layout configuration (I picked the same options as I had originally). But it is all working now. Regards, Gary
