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
|
Locked
Re: Help Setting up JMRI & NCE Power Cab Via USB
Sorry, link omitted. On 11 Feb 2020, at 3:47 PM, Dave Heap <dgheap@...> wrote:
3) The problem described at the following link, possibly combined with (2) above. <> Dave in Australia
|
Locked
Re: Help Setting up JMRI & NCE Power Cab Via USB
On 11 Feb 2020, at 3:02 PM, Thomas Greis < tomgreis@...> wrote: Thank you for your prompt reply to my situation.? Still cannot get the program to stay "online".?
Let me respond sequentially to your suggestions:
1. I had already downloaded the SiLabs driver;? the NCE website directed me to the same link you supplied.? Appears correctly in the device manager, so most likely not the issue?
Agreed.
2. "Com4" still is the only choice I have for the serial port,? but I do not have any serial ports on my computer ( HP Omen desktop )? I sense this may be the problem as I did get an list of errors the system found.
Yes, you have a Virtual Com Port, created by the SiLabs VCP driver.
3. NCE USB Adapter Jumpers - I did not change these from the way they were when I bought the card. I see nothing teling me what the proper setting should be for these 4 jumpers.? They are currently not set on any of the four pin sets ( I assume that would be considered "off " ? ) .? Should they be enabled?
That's what my instructions said "off"
4. Here is the log readout,? sorry if I started it multiple times this evening trying to get it going.
2020-02-10 19:37:28,279 util.Log4JUtil??????????????????????? INFO? - * JMRI log ** [main]
2020-02-10 19:37:28,279 util.Log4JUtil??????????????????????? INFO? - This log is appended to file: C:\Users\User\JMRI\log\messages.log [main]
2020-02-10 19:37:28,279 util.Log4JUtil??????????????????????? INFO? - This log is stored in file: C:\Users\User\JMRI\log\session.log [main]
2020-02-10 19:37:28,279 apps.AppsBase???????????????????????? INFO? - DecoderPro version 4.18+R37ad3d0 starts under Java 1.8.0_241 on Windows 10 x86 v10.0 at Mon Feb 10 19:37:28 PST 2020 [main]
2020-02-10 19:37:28,430 gui3.Apps3??????????????????????????? INFO? - Starting with profile My_JMRI_Railroad.3f2a7782 [main]
2020-02-10 19:37:28,696 node.NodeIdentity???????????????????? INFO? - Using 241b5333-8ef0-4018-a06f-19d49d6487f0 as the JMRI storage identity for profile id 3f2a7782 [AWT-EventQueue-0]
2020-02-10 19:37:28,790 xml.AbstractSerialConnectionConfigXml INFO? - Starting to connect for "NCE" [main]
2020-02-10 19:37:29,123 usbdriver.UsbDriverAdapter??????????? INFO? - NCE USB COM4? port opened at 9600 baud [main]
2020-02-10 19:37:29,249 nce.NceConnectionStatus?????????????? INFO? - NCE EPROM revision = 7.3.0 [AWT-EventQueue-0]
This is the expected reply from the NCE USB and indicates all is well with COM ports, JMRI settings, and NCE USB settings.
Do not change any COM ports, JMRI settings, or NCE USB settings. If you do, all you'll do is go backwards and I'll be forced to give up trying to help you! 2020-02-10 19:38:30,720 jmrix.AbstractMRTrafficController???? WARN? - Timeout on reply to message: 9E consecutive timeouts = 0 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
This is where things go wrong. JMRI has only been talking to the NCE USB (that's where the NCE EPROM revision = 7.3.0 message came from and it told me all jumpers are off).
Now JMRI has asked the NCE USB to tell the Power Cab to enter program track mode.
This hasn't succeeded. I think you'll find the CAB BUS LED (so marked) beside the RJ socket has come on and stuck on. This indicates that the NCE USB is hung up waiting for a Ping from the Power Cab.
This indicates a communications failure between the NCE USB and the Power Cab.
This could be due to: 1) Bad wiring connection via wires 3 & 4 of the cables, sockets connecting the Power Cab to the NCE USB. They aren't needed when the Power Cab is the only device plugged in. They are essential once you have a second device (NCE USB or slave throttle). Do a bit of visual checking. 2) Bad/marginal RS485 driver chips on either/both of the Power Cab and NCE USB. 3) The problem described at the following link, possibly combined with (2) above.
We are suddenly being overwhelmed by this sort of problem and we are suspecting hardware problems... ? Couple of questions that I have:
a. The NCE USB adapter has minimal documentation ( jumper settings for one! )
I've given you them. and no description of what the 2 LED chips mean when they are on or off.? There is one under the USB cable connector and one under the coiled cord connector ( RJ7 ? ).? Do you happen to know if they should be one,? or off?
You tell me what you see and I'll interpret. Normal situation is both off, with brief flashes of both when you ask JMRI to do something. Currently as I type this the adapter is plugged in per directions,? powered up,? and one of the two surface mounted LED's is on:? the one under the coiled cord connector.
The NCE USB is locked up (you have to unplug the RJ connector to reset it).See above. If I plug a power cab throttle into the empty connector on the power cab board interface,? that LED goes out and the other one ( under the USB connector ) goes on. Is this correct behavior??
Do you have two two throttles? If so, we need to know and exactly what they are (as per label on throttle. Note: ? with a loco on the program track the sound only comes on when I plug the throttle in,? otherwise the loco is not active.
You'll never get any sound or life from a loco, nor be able to program a loco unless you have a "Power Cab" plugged into the left hand front socket of the PCP and the LED on the PCP is on.
If you can figure this out,? I think I should be all set.? I'm guessing its a USB/serial port "problem" of some type.
You can rule that out. ? I just don't get what it is...¡...
It's looking like a cabling or hardware issue.
I'm going to have to sign off for the night and have a life.
If the "experts" get you to change settings (and hence set the whole process back), I'm out of this.
Dave in Australia
|
Locked
Re: Help Setting up JMRI & NCE Power Cab Via USB
Tom, On 11 Feb 2020, at 3:11 PM, Thomas Greis <tomgreis@...> wrote:
If you can figure this out, I think I should be all set. I'm guessing its a USB/serial port "problem" of some type. I just don't get what it is...¡... You're looking the wrong place. That is all good. Wait for the email I'm currently composing. Dave in Australia
|
mrclassicman