Kencom, I am a new member, too. Probably in the same phase as you. Not sure whether my advice will help you (but helped to me). If you do not have feedback signals from turnouts, I believe you shouldn't set them as "Monitoring" but "Direct" and "No Feedback" in the Turnout Automation. Some of my turnouts were moving in opposite direction and I believed this could be fixed by table option "Inverted". It did not work. I managed to fix it when editing a turnout in the Layout Panel by the option "Continuing Route Turnout State"- (Edit option here opens another Edit window than if you edit the turnout in the table ouf turnouts).
Jirka, thanks for your response. I tried the strategies you suggested but the problem remains. This time I started using the "DCC++ Monitor window" so I could see the commands and responses on the DCC bus. This proved that I need to have "Monitoring" feedback set to send correct turnout addresses. With "Direct" set, the turnout addresses are wrong. As before, I can get correct "throw" and "close" responses when I use the "Turnout Control" window however, clicking on the Layout graphic turnout control circle send a close command when the turnout is already in the "closed" state. So the problem appears to be that JMRI is generating the incorrect command. I expected that the command should toggle each time I click on the graphic but that is not happening. I can see in the monitor window that DCC++ base station always sends the correct response eg [H1 0] after receiving a packet [T 1 0], however it appears that JMRI does not use that response. Has anyone else successfully implemented turnout control from a JMRI Panel Layout graphic without hardwired feedback signals from the turnouts?
Just to correct my earlier post, the monitor window I mentioned is actually the "DCC++ Traffic Monitor" and it of course monitors the serial bus between JMRI and the DCC++ Base Station (not the DCC bus).
Seems like I am the only one who managed to implement the DCC++ turnout control from the JMRI layout panel. I better went and tried again whether it still works. .. Yes it does! And I tried to use the "DCC++ Traffic Monitor" for the first time. Despite te turnouts are moving correctly when clicking the Layout Panel - the Monitor does not show anything else than "No Sensor/Turnout output Reply" (correct, I do not use any feedback signals so far).
Jirka, In DCC++ Traffic Monitor window, select the "Show raw data" checkbox and you should then see the commands you send to your turnout servos. Regarding my turnout control issues, I plan to do a complete reload and initialization of JMRI and will advise any improvement.
Good hint, thanks Now it shows something more. The picture shows turning of three turnouts from the layout panel. It seems like the packets are sent twice (?or this is the command and response?)... and the harware addresses which I put there as 10, 11, 12 are presented as Address/Subaddr.:
Update on my request for help at post #80 (key issues repeated in next para.) "The problems: (a) when I click on the panel diagram turnout circle to "throw" a turnout that is closed, the corresponding turnout tries to close harder ie move opposite to "throw" direction. (b) when I open the Turnout table and click on the Command button, the turnouts respond with the same symptom." With further observation and using the DCC++ Traffic Monitor (TM) window, I can now add some additional info: When PanelPro is first started, the Turnout Table shows the status of each turnout as "unknown" (in the Command column) and the panel layout diagram indicates "unknown" state for all turnouts by two gaps in the control circle. My first action was to click on the turnout command circle on the layout panel. Traffic Monitor shows that a "close" command was sent; the turnout did not move as it was already in the closed state. The turnout table now shows the status as "thrown" as does the panel diagram. So the first question is "Why did JMRI send a "close" command when the layout graphic changes to the "thrown" state?" Next action is to click the command circle again; JMRI continues to send "close" commands I guess because "No feedback" is provided. (I have all turnouts set to "No Feedback" - I tried the "off" setting but there was no change in responses.) To reiterate, I have full and correct control of all turnouts using the JMRI "Turnout Control" window. If I throw the turnout using that window, the "Current Status" in that window changes to thrown and the turnout physically throws. If I now click on the graphic command circle, a close command is again sent and the turnout responds correctly. So the problem seems to be that the turnout command circle is only ever sending "close" commands. Is this a case of (1) me missing some setup or (2) is this just the way that JMRI currently interacts with DCC++ when there is no hardwired (sensor) feedback to provide turnout status to JMRI? If (2) is the case, could it be corrected by providing a "software feedback" option for turnout status? I believe this could be implemented by JMRI, on start up, issuing a <T> command to DCC++ and parsing the response to set the initial state of all turnouts and then maintaining the turnout status using the DCC++ response to each <T x x> command which comes in the form [Hx x] (as seen in the TM window. Sorry for long post but I would really appreciate any help/advice on the best way to proceed from here.
I know twindad was working on the JMRI interface to work with JMRI....you might want to message him and ask him about the JMRI interactions.
Thanks Scott, I've seen that TwinDad has deep knowledge of JMRI/DCC++ interaction and look forward to any advice he can provide. (I don't want to pester individuals unless they invite me to respond direct ).
Further update (ref post #80 and #87) with an interesting observation: So yesterday I was working with my JMRI/DCC++ setup trying to see if I could get a sensor feedback lash-up working from one turnout. This consisted of taking a signal from my Cobalt frog power terminal (which swaps DCC phase as the turnout changes) through an optocoupler and pulse stretching using a 555 IC, then feeding to a pin on the Ardunio Mega. The result of that test is inconclusive as it requires me to change turnout feedback from "monitoring" to "sensor" which seems to then change turnout addressing to "direct" - I may try to sort this out again later. However, while I was undertaking above testing and had restored my test turnout back to "monitoring" and "no feedback", I had the DCC++ Traffic Monitor window open and observed that for some unknown reason, the JMRI comms to DCC++ had become transmit only, ie commands sent to DCC++ but no response message coming back from DCC++. And here's the key point, in this state, my system started working exactly in the mode I was trying to achieve: ie mouse click on the layout turnout circle and the turnout moved between throw and close and the graphic correctly mimicked the turnout status. Fantastic! Sadly this didn't last, after restarting PanelPro, duplex communications between JMRI and DCC++ was re-established and turnout control from the layout graphic returned to that described previously, ie sends "close" when turnout already closed. However, this incident gives me some hope that JMRI can be made to control the turnouts correctly from the graphic. I have read through the XML files but get no clue from those. The symptom described above (with one-way comms) leads me to speculate that the response message from DCC++ back to JMRI is being parsed incorrectly by the JMRI program and perhaps reversing the internal state of the specific turnout. I'm not a Java programmer, so I don't think I can go any further into this symptom. Maybe this new observation could help someone come up with further ideas to assist me. My next step will be to undertake a complete re-install of all items from scratch including re-drafting of the layout graphic.
After numerous searches I haven't been able to find any info on using DCC++ to control signal lights with JMRI. Anyone have experience doing this?
Update to my post #90: I completed a fresh install of both JMRI (4.4.R1ccf76B) and DCC++ Basestation (1.2.1+) and generated a simple loop layout with one turnout using PanelPro Layout Editor. The same symptoms reported earlier were observed so I concluded that the turnout control I was seeking is not possible using the "Monitoring" mode. After re-reading the Help screen for the Turnout Table, I decided to try using "Direct" control, in the turnout table with "no-feedback". (Note that for no special reason I had previously decided that my turnouts would use addresses starting from 101 and this scheme had previously been entered into DCC++ using the "DCC++ Configure Sensor & Turnouts" table.) To get "Direct" mode working, I had to reprogram my physical turnouts starting from "1", however I am happy to advise that this work-around now provides the operation I was originally seeking. So to summarize my experience so far: With turnouts set to "Monitoring", JMRI sends the <Tn x> commands and allows arbitrary turnout addressing, but does not seem to update the internal turnout status to enable correct control from the layout graphic. The turnout control window buttons do work correctly but status does not update. Alternately, with turnouts set to "Direct", JMRI sends the <a n m x> commands and updates the internal status correctly (it just assumes the turnout has moved as commanded). With "Direct" mode, the turnout addresses started at "1". I'm guessing this comes form the "system name" which for the first turnout defaulted to "DCCPPT1". Maybe if I reloaded the turnout table starting with "DCCPPT101" I could go back to my original addressing scheme but I'll leave that experiment for a later time. With turnout control from the layout graphic now working, my next step is to see if I can get it working from"Engine Driver".
In my first Reply#81 I advised you to use "Direct" and "No Feedback"... My turnouts have correct physical addresses starting from 10 as this was the number I entered with the first entry into the Turnouts Table. The turnout addressing space is then continous. (I have not found any option how to change physical address of a particular turnout later.)
Yes, thanks Jirka your advice was correct. I was following the advice from post #21 which I thought would work. All's well that ends well....
This is very odd. I had DCC++ and JMRI 4.4-R1ccf76b working fine together. then JMRI stopped switching the track power on and off. I thought it was my rendition of DCC++ that I was testing, so I accidently overwrote my version with a new downloaded version of DCC++, and much to my frustration, it still fails to turn track power on and off. I am using the button on the throttle panel. the Power Control panel works, but only if I change the connection from internal to DCC++. and after changing that setting, it still won't work on the throttle panel. I opened the DCC++ Traffic monitor, and tried both the Power Control, and the button on the throttle panel. only the Power Control logs any traffic. I must note, every time I open the Power Control panel, I must change the connection for it to work. Anybody have any ideas? thanks in advance for any help. ~Travis
On a side note....there have been ALOT of bugs and issues with the new version of JMRI with alot of other DCC users
Personally, I haven't liked Java since somebody told me it was a heck of a load on the processor. not sure how much truth there is to that, but it is all about first impressions and influences. but I run it to be able to use JMRI. I may end up building my own hardware control station, kinda like what Dave is doing, but different. ~Travis
A few notes...I was/am experiencing the same thing. After watching the traffic monitor and various feedback in JMRI windows, it appears that JMRI has a bug that isn't handling the <H 1 n> message appropriately. Since DCC++ keeps track of turnout status as well as JMRI, I figured I'd just comment out the return message in DCC++ - and it now works. This would also explain why it was working for you when you lost duplex communication. Since I'm using solenoid turnouts and did some customization to DCC++, I can't use the <ax x x> messages for turnout control. Hopefully someone can look at fixing this in JMRI (or point me to the source that handles return messages from DCC++, a little tough to navigate JMRI source). Here is a blurb from Accessories.cpp from DCC++ where I commented out the code. void Turnout::activate(int s){ char c[20]; data.tStatus=(s>0); // if s>0 set turnout=ON, else if zero or negative set turnout=OFF //Depending on type of turnout, send necessary command switch(TURNOUT_TYPE) { case 0: sprintf(c,"a %d %d %d",data.address,data.subAddress,data.tStatus); SerialCommand:arse(c); case 1: if(data.tStatus){ //Activate open pin for .5 sec to throw switch INTERFACE.print(data.subAddress); digitalWrite(data.subAddress, LOW); delay(500); digitalWrite(data.subAddress, HIGH); } else { //Activate close pin for .5 sec to close switch INTERFACE.print(data.address); digitalWrite(data.address, LOW); delay(500); digitalWrite(data.address, HIGH); } } if(num>0) EEPROM.put(num,data.tStatus); /* Temp comment this out to see if JRMI works. INTERFACE.print("<H"); INTERFACE.print(data.id); if(data.tStatus==0) INTERFACE.print(" 0>"); else INTERFACE.print(" 1>"); */ }
In my attempt to use Xbee wireless serial, I have come about an odd problem. for some reason, my Xbee modules stop communicating when configured for 115200 baud, but work fine at 9600 baud. but JMRI will not allow me to change the baud rate for DCC++, so I am at a loss here. any thoughts or ideas? ~Travis
