Locked
Re: Help with DS64's and JMRI
Really appreciate the clear & detailed inputs provided!
?
Given that mine is a 4¡¯ x 8¡¯ layout, I assume I don¡¯t need to go the LocoNet way. In fact, I don¡¯t know much about LocoNet & have been busy working on the JMRI learning curve, enjoying my multiple trains with Decoder Pro & Panel Pro with SPROG 3!
?
That being said, would be open to advice, if LocoNet makes for an enhanced experience. Also, is LocoNet a must if 2 DS64¡¯s are going to be used (to set the Board ID¡¯s)? Given that I am comfortable with computers and such, which LocoNet product would be best suitable to begin that journey, if I don¡¯t intend using a Digitrax throttle/ command station.
?
Getting back to configuring the DS64 OpSw settings via JMRI ¨C Does it mean that once it¡¯s in programming mode by pressing the hardware OPS button on it, then on Decoder Pro turnout control screen, I need to key in 115:12 in the address box (in case I want to program the OpSw12) and then click on ¡°Thrown¡± or ¡°Close¡± to change that parameter??
?
Does my LocoNet non-availability limitation also mean that the OpSw settings status cannot be read back & hence I will never know the actual OpSw values on the DS64?
?
Thanks & regards,
EsK
?
|
Locked
Re: Help Setting up JMRI & NCE Power Cab Via USB
This may sound simplistic, but look at the circuit board of the USB circuit board and verify that the connectors have the pins soldered. I actually had to solder mine.
(Been several years ago)
Regards,
Jeff Oliver
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Thanks for reminding me about the buffer structure implications. I now remember why I put it aside last time I looked, because I wasn't up with how tight memory was, etc...
After I've had coffee and discussed some NCE issues with a colleague, I'll look at the JMRI code.
Dave in Australia
toggle quoted message
Show quoted text
On 12 Feb 2020, at 2:46 AM, tnt23 < tim.tashpulatov@...> wrote: For the record, here are changes I made to DCC++ BaseStation code for 6 byte packets.
PacketRegister.h:
struct Packet{
? byte buf[11]; // was 10?
? byte nBits;
}; // Packet
PacketRegister.cpp: in?RegisterList::loadPacket starting from Line 70:
if(nBytes==3){
? ? p->nBits=49;
? } else{
? ? buf[6]+=b[3]>>2;? ? ? ? ? ? ? ? ? // b[3], bits 7-2
? ? buf[7]=b[3]<<6;? ? ? ? ? ? ? ? ? ?// b[3], bit 1-0
? ? if(nBytes==4){
? ? ? p->nBits=58;
? ? } else{
? ? ? buf[7]+=b[4]>>3;? ? ? ? ? ? ? ? // b[4], bits 7-3
? ? ? buf[8]=b[4]<<5;? ? ? ? ? ? ? ? ?// b[4], bits 2-0
? ? ? if(nBytes==5){
? ? ? ? p->nBits=67;
? ? ? } else{
? ? ? ? buf[8]+=b[5]>>4;? ? ? ? ? ? ? // b[5], bits 7-4
? ? ? ? buf[9]=b[5]<<4;? ? ? ? ? ? ? ?// b[5], bits 3-0
//? ? ? ? p->nBits=76;
? ? ? ? if (nBytes == 6) {
? ? ? ? ? p->nBits = 76;
? ? ? ? } else {
? ? ? ? ? buf[9]+=b[6]>>5;? ? ? ? ? ? ? // b[6], bits 7-5
? ? ? ? ? buf[10]=b[6]<<3;? ? ? ? ? ? ? ?// b[6], bits 4-0
? ? ? ? ? p->nBits=85;
? ? ? ? }? ? ? ??
? ? ? } // >5 bytes
? ? } // >4 bytes
? } // >3 bytes
|
Locked
Re: Clarifying expection
Thanks for your suggests. I will continue to use the group.
Phil
Hi Phil
Need a lot more information.
I take that you have:
Created a layout panel.
Set up all the blocks with sensors.
Driven the train round manually and all the right blocks went occupied unoccupied the train went round.
You put blocks into sections. (With direction sensors?).
Sections into transits. All set up as all fwd or all rev.
Added signals at all block boundrys. (Masts or Heads?)
All SML for masts or SSL for heads set up and working.
Dispatcher options set correctly.(using heads or masts must be set correctly).
If you use the train set up exactly as shown you are driving the train......drive the train manually through the transit and check the occupancy and signals.
Set to automatic.
Remove the back and forth and see if that works.
Then try B&F setting continious with a delay.
I normally recommend starting with 2 blocks, 2 section, 1 transit. Then if that works add one block and section at a time. Saves years of frustration. Stating with threes on the right track.
Steve G.
|
I have noticed what seems to be this same symptom a couple of times as well. A simple restart of JMRI and all is well, the roster "returns". No rebuild roster needed, the roster.xml file is unchanged (it's in DropBox, so I see change history).
I enabled roster debug a while back, but the messages were identical for the failed attempt as for the successful attempt. In both cases, the "readFile sees xx children" and the subsequent "Add entry..." lines are as expected.
Tried several more times and could not get the failure to repeat.
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
(sorry for polluting the thread)
I couldn't help but opened an issue with JMRI repository, to save a bit of traffic here.
Dave, if you will be making a custom build for me, could you please 1) add some logging there to dump the whole 'M' command, and 2) instead of increasing length condition from 5 to 6, just change the 'for' cycle in line 2445 to run until num_bytes-1? Thanks again.
Regards
Tim
|
sorry for the late entry but I am having similar problems with my new printer -? ?it prints the manifests but in minuscule fonts.
then printer is an HP 2600 and is the default printer
computer is an? Acer running win 10 and the jmri is V4.11 i think.
All other devices in the house print fine
from above discussion it looks like the quick fix would be to print to a pdf.? Not quite sure how to get this done,
As always, thanks for your help
Gene
|
It makes no difference which I position the mouse button over I do not in any case get the drag image to move into any of the spaces on the icon panel. No worries, in the middle of the night I woke up with a solution! I just used the turnout function, moved two of each to the panel, rotated one of each 180 degrees, resized them to 75%, and ?placed them so that they look like a double cross over. They are all numbered with the same turnout number so they work in unison ! Done deal, working for me. A rather around the block solution but it works. Thanks for the input, this baby is put to bed! Lol ? Terry Cummins S.E. Michigan ? Sent from for Windows 10 ?
toggle quoted message
Show quoted text
From: Dave SandSent: Monday, February 10, 2020 9:38 PM To: [email protected]Subject: Re: [jmriusers] Undefined problem double x over in Panel Pro editor #paneleditor ? Terry, Just to be clear, you position the mouse over a turnout name, click and hold the mouse button, move the move over a "undefined" box and release the mouse button? What version of JMRI are you running? ----- Original message ----- From: mrclassicman <mrclassicman512@...> Subject: Re: [jmriusers] Undefined problem double x over in Panel Pro editor #paneleditor Date: Monday, February 10, 2020 8:19 PM Dave, I uploaded a screen shot of the Panel Pro Editor screen open with the "undefined boxes". Sorry I don't know why the screen shot is so fuzzy. Additionally I tried as you suggested moving the names to the boxes and or the icons to the boxes and there is no common dragging the image, as with all of the other placed icons, present. There must be something very simple that I am missing as everything else has worked perfectly! So I am back to looking at this tomorrow. There must be some means for defining the required boxes and it must be deep in the program. The image is has been loaded into the photo section under the heading "Panel Pro Editor X over" -- Terry CumminsS.E. Michigan
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
For the record, here are changes I made to DCC++ BaseStation code for 6 byte packets. PacketRegister.h:
struct Packet{
? byte buf[11]; // was 10?
? byte nBits;
}; // Packet
PacketRegister.cpp: in?RegisterList::loadPacket starting from Line 70:
if(nBytes==3){
? ? p->nBits=49;
? } else{
? ? buf[6]+=b[3]>>2;? ? ? ? ? ? ? ? ? // b[3], bits 7-2
? ? buf[7]=b[3]<<6;? ? ? ? ? ? ? ? ? ?// b[3], bit 1-0
? ? if(nBytes==4){
? ? ? p->nBits=58;
? ? } else{
? ? ? buf[7]+=b[4]>>3;? ? ? ? ? ? ? ? // b[4], bits 7-3
? ? ? buf[8]=b[4]<<5;? ? ? ? ? ? ? ? ?// b[4], bits 2-0
? ? ? if(nBytes==5){
? ? ? ? p->nBits=67;
? ? ? } else{
? ? ? ? buf[8]+=b[5]>>4;? ? ? ? ? ? ? // b[5], bits 7-4
? ? ? ? buf[9]=b[5]<<4;? ? ? ? ? ? ? ?// b[5], bits 3-0
//? ? ? ? p->nBits=76;
? ? ? ? if (nBytes == 6) {
? ? ? ? ? p->nBits = 76;
? ? ? ? } else {
? ? ? ? ? buf[9]+=b[6]>>5;? ? ? ? ? ? ? // b[6], bits 7-5
? ? ? ? ? buf[10]=b[6]<<3;? ? ? ? ? ? ? ?// b[6], bits 4-0
? ? ? ? ? p->nBits=85;
? ? ? ? }? ? ? ??
? ? ? } // >5 bytes
? ? } // >4 bytes
? } // >3 bytes
and in?RegisterList::writeTextPacket, starting from Line 203:
void RegisterList::writeTextPacket(char *s) volatile{
??
? int nReg;
? byte b[7];
? int nBytes;
? volatile RegisterList *regs;
? ??
? nBytes=sscanf(s,"%d %x %x %x %x %x %x",&nReg,b,b+1,b+2,b+3,b+4, b+5)-1;
?
//INTERFACE.print(nBytes);
??
? if(nBytes<2 || nBytes>6){? ? // invalid valid packet
? ? INTERFACE.print("<mInvalid Packet>");
? ? return;
? }
? ? ? ? ?
? loadPacket(nReg,b,nBytes,0,1);
? ??
} // RegisterList::writeTextPacket()
Sorry I failed to make myself clear regarding sscanf() behavior, certainly it will report correct number of arguments scanned for 2, 3, 4, and 5 cases. What I meant was that it would report nBytes=6 when there are more arguments passed to it than is noted in its format string, and thus RegisterList::writeTextPacket() won't report this as an error. Regards Tim
|
Locked
Re: basic hook up laptop to powerhouse
#nce
Update, spent a couple of hours late into the night trying everything that was suggested. Nothing seemed to change. Finally decided just to clear everything off and start over this morning. So I deleted the entire program and reinstalled it this morning. I do not know what is different, but the system is working! I have throttle control and I have programmability. thanks for all the help and suggestions, Bruce Mount Airy, Maryland
toggle quoted message
Show quoted text
On Feb 10, 2020, at 8:33 PM, Dave Heap <dgheap@...> wrote:
Bruce,
On 11 Feb 2020, at 8:21 AM, forfoum@... wrote:
Go into Windows Device Manager, view COM ports.. Now disconnect / connect your RS-232/USB cable from the computer and note the change.. Should vanish and reappear. If you see nothing, then the device driver is not loaded or the device has a problem. If no driver loaded but device is operational, it should show up as unknown device. FTDI USB-Serial Drivers from:
<>
Dave in Australia
|
It makes no difference which I position the mouse button over I do not in any case get the drag image to move into any of the spaces on the icon panel. No worries, in the middle of the night I woke up with a solution! I just used the turnout function, moved two of each to the panel, rotated one of each 180 degrees, resized them to 75%, and ?placed them so that they look like a double cross over. They are all numbered with the same turnout number so they work in unison ! Done deal, working for me. A rather around the block solution but it works. Thanks for the input, this baby is put to bed! Lol ? Terry Cummins S.E. Michigan ? Sent from for Windows 10 ?
toggle quoted message
Show quoted text
From: Dave SandSent: Monday, February 10, 2020 9:38 PM To: [email protected]Subject: Re: [jmriusers] Undefined problem double x over in Panel Pro editor #paneleditor ? Terry, Just to be clear, you position the mouse over a turnout name, click and hold the mouse button, move the move over a "undefined" box and release the mouse button? What version of JMRI are you running? ----- Original message ----- From: mrclassicman <mrclassicman512@...> Subject: Re: [jmriusers] Undefined problem double x over in Panel Pro editor #paneleditor Date: Monday, February 10, 2020 8:19 PM Dave, I uploaded a screen shot of the Panel Pro Editor screen open with the "undefined boxes". Sorry I don't know why the screen shot is so fuzzy. Additionally I tried as you suggested moving the names to the boxes and or the icons to the boxes and there is no common dragging the image, as with all of the other placed icons, present. There must be something very simple that I am missing as everything else has worked perfectly! So I am back to looking at this tomorrow. There must be some means for defining the required boxes and it must be deep in the program. The image is has been loaded into the photo section under the heading "Panel Pro Editor X over" -- Terry CumminsS.E. Michigan
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Tim, Dave,
"By adding debug print of nBytes I learned it is always set to 6, and it is the number of parameters the "%d %x %x %x %x %x"?format
string expects (1 decimal for register number, and 5 hexes for
parameters). It appears sscanf() just ignores the rest of input once it
successfully stuffes all variables in its list."
It is very easy to make this code a lot more robust so it catches the 'too many parameters' as an invalid packet. Instead of passing in the actual message, pass in a modified one with a known trailing character (any will do, say 'X'). So in the example the string going in would become:
"M 0 1 2 3 4 5 6X"
and the scanf string:
"%d %x %x %x %x %xX"
No difference in result for this message, but if you have that extra input as in "M 0 1 2 3 4 5 6 7 8", (again passed in with the appended 'X' as):
"M 0 1 2 3 4 5 6 7 8X"
Using scanf with the same "%d %x %x %x %x %xX" now fails, detecting invalid packet, because it cannot match the now required 'X'.
It may not be a good moment for this change as you want the smallest possible modification at this point, but it is easy defensive programming that can catch unexpected issues, and could be something to keep in mind for later.
Wouter
Dave,
What does your modified code look like? Please show us.
Will share the changed pieces tonight once I am at my home computer.
?
My reading (I'm not a C++ speaker) of the code is that the sscanf ?function returns the number of successful matches*, not the number of parameters. So nBytes returns the actual number of parameters (minus 1 for the register parameter).
That is correct. My experience is based on feeding different variants of 'M' command to DCC++ Base Station via serial console, and watching the result. Started with '<M 0 1>', got '<mInvalid packet>' response in accordance with the (unmodified original) code:
| nBytes=sscanf(s,"%d %x %x %x %x %x",&nReg,b,b+1,b+2,b+3,b+4)-1; |
| ? |
| if(nBytes<2 || nBytes>5){ // invalid valid packet |
| INTERFACE.print("<mInvalid Packet>"); |
| ? |
Next was the well-behaved '<M 0 1 2 3 4 5>' which went through perfectly silent.
Then I tried '<M 0 1 2 3 4 5 6 7 8'> and did not get error response. By adding debug print of nBytes I learned it is always set to 6, and it is the number of parameters the "%d %x %x %x %x %x"?format string expects (1 decimal for register number, and 5 hexes for parameters). It appears sscanf() just ignores the rest of input once it successfully stuffes all variables in its list.
But I believe it is irrelevant at this point. More important is the knowledge that JMRI always passes the packet bytes to the DCC++ including last checksumbyte. I will need to think this over, too.
Regards
Tim
?
nBytes is the number of bytes specified to loadPacket?
?
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Next was the well-behaved '<M 0 1 2 3 4 5>' which went through perfectly silent.
Then I tried '<M 0 1 2 3 4 5 6 7 8'> and did not get error response. By adding debug print of nBytes I learned it is always set to 6, and it is the number of parameters the "%d %x %x %x %x %x"?format string expects (1 decimal for register number, and 5 hexes for parameters). It appears sscanf() just ignores the rest of input once it successfully stuffes all variables in its list. But you didn't try ?'<M 0 1 2 3>' . I don't think you'll get nBytes=6 when the number of supplied parameters are less than those in the format string and variables). See <>
Please set the DCC++ code as per my crossed-in-delivery email.
Dave in Australia
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
To late at night for me to be thinking code. We want to minimise changes and possible breaking of existing code, JMRI and other.
Please change:
1) Documentation at lines 482 ff of SerialCommand.cpp needs extra parameter adding.
2) Change??PacketRegister.cpp, method?writeTextPacket?as below: ///////////////////////////////////////////////////////////////////////////////
void RegisterList::writeTextPacket(char *s) volatile{ ?? ? int nReg; ? byte b[7]; ? int nBytes; ? volatile RegisterList *regs; ? ?? ? nBytes=sscanf(s,"%d %x %x %x %x %x %x",&nReg,b,b+1,b+2,b+3,b+4,b+5)-1; ?? ? if(nBytes<2 || nBytes>6){ ? ?// invalid packet ? ? INTERFACE.print("<mInvalid Packet>"); ? ? return; ? } ? ? ? ? ? ? loadPacket(nReg,b,nBytes,0,1); ? ?? } // RegisterList::writeTextPacket() ?? ///////////////////////////////////////////////////////////////////////////////
I'll change: Line 2441 of??in the private build to be: ? ?if?(num_bytes?<?2?||?num_bytes?> 6)?return(null);
You can then test the result with your DCC++ hardware.
Dave in Australia
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Dave,
What does your modified code look like? Please show us.
Will share the changed pieces tonight once I am at my home computer.
?
My reading (I'm not a C++ speaker) of the code is that the sscanf ?function returns the number of successful matches*, not the number of parameters. So nBytes returns the actual number of parameters (minus 1 for the register parameter).
That is correct. My experience is based on feeding different variants of 'M' command to DCC++ Base Station via serial console, and watching the result. Started with '<M 0 1>', got '<mInvalid packet>' response in accordance with the (unmodified original) code:
| nBytes=sscanf(s,"%d %x %x %x %x %x",&nReg,b,b+1,b+2,b+3,b+4)-1; |
| ? |
| if(nBytes<2 || nBytes>5){ // invalid valid packet |
| INTERFACE.print("<mInvalid Packet>"); |
| ? |
Next was the well-behaved '<M 0 1 2 3 4 5>' which went through perfectly silent. Then I tried '<M 0 1 2 3 4 5 6 7 8'> and did not get error response. By adding debug print of nBytes I learned it is always set to 6, and it is the number of parameters the " %d %x %x %x %x %x"?format string expects (1 decimal for register number, and 5 hexes for parameters). It appears sscanf() just ignores the rest of input once it successfully stuffes all variables in its list. But I believe it is irrelevant at this point. More important is the knowledge that JMRI always passes the packet bytes to the DCC++ including last checksumbyte. I will need to think this over, too. Regards Tim
?
nBytes is the number of bytes specified to loadPacket?
?
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Tim,(It is probably worth nothing to note that DCC++ code, as it seems, will not spot extra bytes in 'M' message. The sscanf template used will always try to read up to 5 or 6 parameters, and will always return maximum number, 5 or 6, even if being fed 10 or 15 parameters)
That needs updating to scan the extra parameter and load it into the extra element of the array.
What does your modified code look like? Please show us.
My reading (I'm not a C++ speaker) of the code is that the sscanf ?function returns the number of successful matches*, not the number of parameters. So nBytes returns the actual number of parameters (minus 1 for the register parameter).
nBytes is the number of bytes specified to loadPacket?
*<>
Dave in Australia
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Of these 6 bytes, last checksum byte does not need to be passed to DCC++ as it is calculated internally by DCC++ code when forming the packet. This means that 'M' command should be passing 5 bytes to DCC++, as follows:
<M 0 1 2 3 4 5>
, where the first 0 after M is Register number and should not count in num_bytes. The problem is that the NmraPacket class in JMRI creates and appends the checksum for every method (packet type) defined. <> We can't change that code without breaking every other system.
Packet lengths vary (they are not all 6 bytes).
Dropping the last byte of every M command changes the DCC++ specification as far as I can see and would break any non-JMRI software using the DCC++ system.
But too late in the day for this sort of thinking...
Dave in Australia
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Dave,
<>
?
if?(num_bytes?<?2?||?num_bytes?>?5)?return(null);
This makes me think the DCCppMessage.java is worth updating for 6 byte packets, too :)
Agreed, provided the DCC++code is updated as well
(It is probably worth nothing to note that DCC++ code, as it seems, will not spot extra bytes in 'M' message. The sscanf template used will always try to read up to 5 or 6 parameters, and will always return maximum number, 5 or 6, even if being fed 10 or 15 parameters)
That needs updating to scan the extra parameter and load it into the extra element of the array.
Guess you haven't got a checkout of the JMRI code?
?
I could do you a private build with that change later if need be..
No, I did not checkout JMRI sources as I plain have no idea what to do with them in the first place :) Yet if you could build a test version for me that would be awesome. Thanks a bunch!
Will have to be tomorrow. After dinner here and computers shut down due to storms.
Dave in Australia
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
On another thought, though: Extended Decoder Control Packet address for operations mode programming (clause 485 on page 10 of s-9.2.1) looks like this:
{preamble} 10AAAAAA 0 0AAA0AA1 0 (1110CCVV 0 VVVVVVVV 0 DDDDDDDD) 0 EEEEEEEE 1
Of these 6 bytes, last checksum byte does not need to be passed to DCC++ as it is calculated internally by DCC++ code when forming the packet. This means that 'M' command should be passing 5 bytes to DCC++, as follows:
<M 0 1 2 3 4 5>
, where the first 0 after M is Register number and should not count in num_bytes. Is there a way to add parameters debugging output to console or log for the? makeWriteDCCPacketMainMsg?routine? Regards Tim
|
Locked
Re: JMRI and DCC++: Exception with Simple Programmer in Ops Accessory Byte/Extended Byte mode
#dccpp
#4-18
Dave,
<>
?
if?(num_bytes?<?2?||?num_bytes?>?5)?return(null);
This makes me think the DCCppMessage.java is worth updating for 6 byte packets, too :) (It is probably worth nothing to note that DCC++ code, as it seems, will not spot extra bytes in 'M' message. The sscanf template used will always try to read up to 5 or 6 parameters, and will always return maximum number, 5 or 6, even if being fed 10 or 15 parameters)
Guess you haven't got a checkout of the JMRI code?
?
I could do you a private build with that change later if need be..
No, I did not checkout JMRI sources as I plain have no idea what to do with them in the first place :) Yet if you could build a test version for me that would be awesome. Thanks a bunch! Regards Tim
|
mrclassicman