|
It was all working in Nscale to set the throttle and run trains, etc, on the Raspberry Pi 3B, but when I moved it to HO, it¡¯s failing to get the throttle.
I¡¯ve done some research and there¡¯s mention of stealing the loco but before I chase that, let me see what you guys recommend as the standard way.
Do you have to open a new throttle from Panel Pro, and maybe set the address of the loco?? Or will the script, like the sample automat one work just by itself?
I am able to acquire the address using the walk around throttle.? But, before I have the script try it, I release it.? It still fails to get it.
So, my specifics: Digitrax Zephyr 50. PR3 interface between Raspberry and loconet. Now, I¡¯m able to throw my turnouts with the script, and the script as well as the panel pro registers the loco in the block. Raspberry Pi 3B running Rasbarian Panel Pro 4.14+Rdo60eob Java version 1.8.0_65(en)
What good troubleshooting tools/apps/ menu items should I use?
I open the monitor loconet, and it mentions setting speed of loco in slot 6 to 0. ?(I¡¯m not doing that) Script ooutput shows the couldn¡¯t assign throttle message and other sensor stuff. Monitor slots shows address 1 a consist. I released that. It also shows address 3 in use. ? I cannot aquire it using the UT1 throttle. ? I can aquire it on the zephyr throttle. I always aquire 1 so I know 3 is released.
I release both throttles and try to run the script again and same message that it cannot aquire the throttle and it exits.
The call to aquire the throttle has the second parameter set to True.
Not sure where to go from here.
|
Kirk,
try updating to 4.16 (or wait approx. five weeks and try 4.18).
There have been quite a few improvements to Loconet throttle handling /
stealing since 4.14 (most already from 4.12 to 4.14, but some afterwards
too, IIRC)
Also make sure the connection settings are correct (PR3, DCS50, not some
other command station).
And you can try resetting the DCS50 (one of those legendary OpSwitches)
before running your script. The fact that there is something other than
you setting slot 6 to 0 and that you can't acquire the loco with the UT1
points to a confused command station ;) or maybe one of the jump ports
has an address acquired. Do you know what address was active on Slot 6?
Or maybe the DCS50 still has some N scale locos in its recall list and
is overloaded with the new H0 locos, afair it can only handle 10 slots.
Again, resetting the command station can help.
Good luck,
Heiko
--
eMails verschl¨¹sseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung:
|
Kirk,
If I had to do some guessing, I would wonder whether one of the DCS50 "Jump" throttles got assigned to a loco, and that this loco is (still) associated with slot 6...
Have you tried to "dispatch" any locos assigned to the DCS50 "jump" throttles? That might clear up the slot 6 LocoNet messages... (Check the DCS50 manual for instructions on dispatching the jump throttles; I have never used a jump throttle, so I am clueless on the process!)
Regards,
Billybob
|
Let me add this:
My UT1 can aquire the address of the loco.? It¡¯s 3, the default for new decoders. ?(I only have one HO engine with sound, the spretrum 4-4-0, Richmond.? Also, I only have a few Nscale engines, too.? A 2-6-0 Spretrum, and their 4-6-0, both modern small steamers.? I also have some scratch built.? I cannot really remember any of them on address 6.? I had some amusement part rides with deciders, but they were all above 10.).?
Let me also state that I can aquire address 3 with the hand held throttle, and the throttle on the zephyr.? And I can, using panel pro, create a new ¡°soft¡± throttle and can aquire address 3 and run the loco, from the raspberry throttle UI.?
?If I have the loco set with the soft throttle, the hand held can steal it, without the soft throttle releasing it.? But the soft throttle cannot aquire it unless the handheld releases it.
When I run the script, the script fails to aquire the address, without any other throttles having the address.? The problem is only in the script, and with HO.? Well, I haven¡¯t disconnected the zephyr and reconnected it to the Nscale loop for a while, so, I¡¯m not totally sure the Nscale will work at this point.? Just that it has worked in the past, like 4 or 5 months ago.? Then, I was able to have the raspberry control my Nscale loop, sending the train out into a loop for a few turns and the bring it back.
I will try to see if the soft throttle can aquire a different address.? So, it could be just something with the HO loco or address?
On Friday, November 15, 2019, billybob experimenter < jawhugrps@...> wrote: Kirk,
If I had to do some guessing, I would wonder whether one of the DCS50 "Jump" throttles got assigned to a loco, and that this loco is (still) associated with slot 6...
Have you tried to "dispatch" any locos assigned to the DCS50 "jump" throttles?? That might clear up the slot 6 LocoNet messages... (Check the DCS50 manual for instructions on dispatching the jump throttles; I have never used a jump throttle, so I am clueless on the process!)
Regards,
Billybob
|
Kirk,
"Slot 6" might be assigned to loco address 6. Or loco address 0. Or loco address 3. or loco addres 2154, or any other loco address between 0 and something over 9900 (but not quite to 9999, with Digitrax systems). "Slot 6" is NOT NECESSARILY associated with "DCC address 6". In fact, it typically will not be.
Exact slot assignments depends entirely upon the sequence in which locos are acquired and dispatched/dropped, and the way that various throttles attempt to re-acquire locos when they become powered-up and/or attached to a live LocoNet.
It is generally only possible to know what address is associated with "Slot 6" when some LocoNet agent "queries" the command station for "slot 6" information. JMRI can perform that function, as part of the LocoNet "Slot Monitor". See .
To interpret that tool's results when you use the tool, you need to reference the "slot number" that you see in LocoNet Monitor in the left-most "Slot" column of the tool's table - in your case, look for the row for "Slot" number 6. Then look at that row's "Address" column to determine the address assigned to the slot. Once you know that address, try to dial that address on a live throttle. You will likely get the "Steal" message (or some LED color indication on those throttles which cannot display alphanumeric information).
In the image at the top of the above-referenced web page, slot 6 just so happens to be assigned to address 6. (This is not typically what users see, unless they just happen to acquire locos of particular numbers in a particular order from a command station with a particularly-clean slot table.)
This assignment of address 6 to slot 6 just happens to be coincidental, and this coincidence is likely because the JMRI developer who created the image did not use much imagination (or realism!) when "acquiring" locomotives before creating the image... Perhaps that image needs to be updated to show a more-typical situation where random addresses were acquired, rather than sequential addresses.
Regards,
Billybob
|
Good news!
I reset the zephyr, nope. I changed to have the script try to aquire address 4.? Still errored, so, it¡¯s not the loco. On a chance, I changed the setThrottle second parameter to False.
It worked!? The script acquired the address and the loco took off.? Yeah.
I think that second parameter is false, for two digit address, and true for four digit address.
Now, I¡¯m running.
I¡¯ll start another thread with my next problem, since it¡¯s not about the throttle, anymore.
On Friday, November 15, 2019, billybob experimenter < jawhugrps@...> wrote: Kirk,
"Slot 6" might be assigned to loco address 6.? Or loco address 0.? Or loco address 3. or loco addres 2154, or any other loco address between 0 and something over 9900 (but not quite to 9999, with Digitrax systems).? "Slot 6" is NOT NECESSARILY associated with "DCC address 6".? In fact, it typically will not be.
Exact slot assignments depends entirely upon the sequence in which locos are acquired and dispatched/dropped, and the way that various throttles attempt to re-acquire locos when they become powered-up and/or attached to a live LocoNet.
It is generally only possible to know what address is associated with "Slot 6" when some LocoNet agent "queries" the command station for "slot 6" information.? JMRI can perform that function, as part of the LocoNet "Slot Monitor".? See .?
To interpret that tool's results when you use the tool, you need to reference the "slot number" that you see in LocoNet Monitor in the left-most "Slot" column of the tool's table - in your case, look for the row for "Slot" number 6.? Then look at that row's "Address" column to determine the address assigned to the slot.? Once you know that address, try to dial that address on a live throttle.? You will likely get the "Steal" message (or some LED color indication on those throttles which cannot display alphanumeric information).
In the image at the top of the above-referenced web page, slot 6 just so happens to be assigned to address 6.? (This is not typically what users see, unless they just happen to acquire locos of particular numbers in a particular order from a command station with a particularly-clean slot table.)?
This assignment of address 6 to slot 6 just happens to be coincidental, and this coincidence is likely because the JMRI developer who created the image did not use much imagination (or realism!) when "acquiring" locomotives before creating the image...? Perhaps that image needs to be updated to show a more-typical situation where random addresses were acquired, rather than sequential addresses.
Regards,
Billybob
|
Back to throttle problems again.
Jmri is able to aquire the loco on a DCC address just fine.? And it starts it.? But suddenly and randomly, the loco stops.? I checked the loconet monitor window and I see that a command was giving for the loco to run at speed 0.? It just occurs.? It¡¯s like a command comes from some rogue engineer.
I do have the zypher set to run the same loco.? So, it seems logical that the command station tells the loco to be at speed zero.? I¡¯ve tried to set the zypher a different address, but when I do, JMRI doesn¡¯t run the loco either.? I¡¯ve also tried to open a ¡°soft¡± throttle in JMRI and that doesn¡¯t seem to get it to work either.
As a side note, I¡¯ve also looked at the slot monitor and have cleared out all of the addresses for each slot.? But when I reopen it, I¡¯ve seen some slots being used for locos that I haven¡¯t tried to address.? Even a consist shows up.? I don¡¯t understand where these are coming from.? Is there a way to clear this from memory?? And is this a JMRI thing or a digitrax zypher thing?
Thanks.
On Saturday, November 16, 2019, Kirk Ervin via Groups.Io <kirkajervin= [email protected]> wrote: Good news!
I reset the zephyr, nope. I changed to have the script try to aquire address 4.? Still errored, so, it¡¯s not the loco. On a chance, I changed the setThrottle second parameter to False.
It worked!? The script acquired the address and the loco took off.? Yeah.
I think that second parameter is false, for two digit address, and true for four digit address.
Now, I¡¯m running.
I¡¯ll start another thread with my next problem, since it¡¯s not about the throttle, anymore. On Friday, November 15, 2019, billybob experimenter < jawhugrps@...> wrote: Kirk,
"Slot 6" might be assigned to loco address 6.? Or loco address 0.? Or loco address 3. or loco addres 2154, or any other loco address between 0 and something over 9900 (but not quite to 9999, with Digitrax systems).? "Slot 6" is NOT NECESSARILY associated with "DCC address 6".? In fact, it typically will not be.
Exact slot assignments depends entirely upon the sequence in which locos are acquired and dispatched/dropped, and the way that various throttles attempt to re-acquire locos when they become powered-up and/or attached to a live LocoNet.
It is generally only possible to know what address is associated with "Slot 6" when some LocoNet agent "queries" the command station for "slot 6" information.? JMRI can perform that function, as part of the LocoNet "Slot Monitor".? See .?
To interpret that tool's results when you use the tool, you need to reference the "slot number" that you see in LocoNet Monitor in the left-most "Slot" column of the tool's table - in your case, look for the row for "Slot" number 6.? Then look at that row's "Address" column to determine the address assigned to the slot.? Once you know that address, try to dial that address on a live throttle.? You will likely get the "Steal" message (or some LED color indication on those throttles which cannot display alphanumeric information).
In the image at the top of the above-referenced web page, slot 6 just so happens to be assigned to address 6.? (This is not typically what users see, unless they just happen to acquire locos of particular numbers in a particular order from a command station with a particularly-clean slot table.)?
This assignment of address 6 to slot 6 just happens to be coincidental, and this coincidence is likely because the JMRI developer who created the image did not use much imagination (or realism!) when "acquiring" locomotives before creating the image...? Perhaps that image needs to be updated to show a more-typical situation where random addresses were acquired, rather than sequential addresses.
Regards,
Billybob
|
Kirk,
Yes, you are experiencing LocoNet-specific problems. Having the loco dialed-up on the Zephyr throttle is _likely_ the cause of your JMRI throttle getting set back to speed step 0, as you saw in the LocoNet Monitor.
You really need to get rid of the loco from the Zephyr. The easiest way to do this is to dial up and successfully acquire some other Loco on the Zephyr.
Regards,
Billybob
|
First, drop the decoder from the Zephyr by selecting some other address. When the Zephyr has a locomotive selected, even one with a JMRI throttle also attached, the Zephyr sends its intended speed periodically. After that, you should be able to select that locomotive via JMRI. Bob On Feb 25, 2020, at 11:06 AM, Kirk Ervin <kirkajervin@...> wrote:
Back to throttle problems again.
Jmri is able to aquire the loco on a DCC address just fine. And it starts it. But suddenly and randomly, the loco stops. I checked the loconet monitor window and I see that a command was giving for the loco to run at speed 0. It just occurs. It¡¯s like a command comes from some rogue engineer.
I do have the zypher set to run the same loco. So, it seems logical that the command station tells the loco to be at speed zero. I¡¯ve tried to set the zypher a different address, but when I do, JMRI doesn¡¯t run the loco either. I¡¯ve also tried to open a ¡°soft¡± throttle in JMRI and that doesn¡¯t seem to get it to work either.
As a side note, I¡¯ve also looked at the slot monitor and have cleared out all of the addresses for each slot. But when I reopen it, I¡¯ve seen some slots being used for locos that I haven¡¯t tried to address. Even a consist shows up. I don¡¯t understand where these are coming from. Is there a way to clear this from memory? And is this a JMRI thing or a digitrax zypher thing?
Thanks.
On Saturday, November 16, 2019, Kirk Ervin via Groups.Io <kirkajervin@...> wrote:
Good news!
I reset the zephyr, nope.
I changed to have the script try to aquire address 4. Still errored, so, it¡¯s not the loco.
On a chance, I changed the setThrottle second parameter to False.
It worked! The script acquired the address and the loco took off. Yeah.
I think that second parameter is false, for two digit address, and true for four digit address.
Now, I¡¯m running.
I¡¯ll start another thread with my next problem, since it¡¯s not about the throttle, anymore.
On Friday, November 15, 2019, billybob experimenter <jawhugrps@...> wrote:
Kirk,
"Slot 6" might be assigned to loco address 6. Or loco address 0. Or loco address 3. or loco addres 2154, or any other loco address between 0 and something over 9900 (but not quite to 9999, with Digitrax systems). "Slot 6" is NOT NECESSARILY associated with "DCC address 6". In fact, it typically will not be.
Exact slot assignments depends entirely upon the sequence in which locos are acquired and dispatched/dropped, and the way that various throttles attempt to re-acquire locos when they become powered-up and/or attached to a live LocoNet.
It is generally only possible to know what address is associated with "Slot 6" when some LocoNet agent "queries" the command station for "slot 6" information. JMRI can perform that function, as part of the LocoNet "Slot Monitor". See .
To interpret that tool's results when you use the tool, you need to reference the "slot number" that you see in LocoNet Monitor in the left-most "Slot" column of the tool's table - in your case, look for the row for "Slot" number 6. Then look at that row's "Address" column to determine the address assigned to the slot. Once you know that address, try to dial that address on a live throttle. You will likely get the "Steal" message (or some LED color indication on those throttles which cannot display alphanumeric information).
In the image at the top of the above-referenced web page, slot 6 just so happens to be assigned to address 6. (This is not typically what users see, unless they just happen to acquire locos of particular numbers in a particular order from a command station with a particularly-clean slot table.)
This assignment of address 6 to slot 6 just happens to be coincidental, and this coincidence is likely because the JMRI developer who created the image did not use much imagination (or realism!) when "acquiring" locomotives before creating the image... Perhaps that image needs to be updated to show a more-typical situation where random addresses were acquired, rather than sequential addresses.
Regards,
Billybob
-- Bob Jacobsen rgj1927@...
|
I just want to give an update.
I set the zypher address to 1.
Then I ran the script.? But still the engine isn¡¯t aquired.? I set the parameter to the throttle function as True.? It still failed.? Then I set it back to False, and it ran fine.? Strange that it didn¡¯t aquire the loco.
Anyway, thank you all for responding.? You provide excellent feedback with this group.? Kudos!?
On Tuesday, February 25, 2020, Bob Jacobsen < rgj1927@...> wrote: First, drop the decoder from the Zephyr by selecting some other address.? When the Zephyr has a locomotive selected, even one with a JMRI throttle also attached, the Zephyr sends its intended speed periodically.
After that, you should be able to select that locomotive via JMRI.
Bob
> On Feb 25, 2020, at 11:06 AM, Kirk Ervin <kirkajervin@...> wrote:
>
> Back to throttle problems again.
>
> Jmri is able to aquire the loco on a DCC address just fine.? And it starts it.? But suddenly and randomly, the loco stops.? I checked the loconet monitor window and I see that a command was giving for the loco to run at speed 0.? It just occurs.? It¡¯s like a command comes from some rogue engineer.
>
> I do have the zypher set to run the same loco.? So, it seems logical that the command station tells the loco to be at speed zero.? I¡¯ve tried to set the zypher a different address, but when I do, JMRI doesn¡¯t run the loco either.? I¡¯ve also tried to open a ¡°soft¡± throttle in JMRI and that doesn¡¯t seem to get it to work either.
>
> As a side note, I¡¯ve also looked at the slot monitor and have cleared out all of the addresses for each slot.? But when I reopen it, I¡¯ve seen some slots being used for locos that I haven¡¯t tried to address.? Even a consist shows up.? I don¡¯t understand where these are coming from.? Is there a way to clear this from memory?? And is this a JMRI thing or a digitrax zypher thing?
>
> Thanks.
>
> On Saturday, November 16, 2019, Kirk Ervin via Groups.Io <kirkajervin=gmail.com@groups.io> wrote:
> Good news!
>
> I reset the zephyr, nope.
> I changed to have the script try to aquire address 4.? Still errored, so, it¡¯s not the loco.
> On a chance, I changed the setThrottle second parameter to False.
>
> It worked!? The script acquired the address and the loco took off.? Yeah.
>
> I think that second parameter is false, for two digit address, and true for four digit address.
>
> Now, I¡¯m running.
>
> I¡¯ll start another thread with my next problem, since it¡¯s not about the throttle, anymore.
>
> On Friday, November 15, 2019, billybob experimenter <jawhugrps@...> wrote:
> Kirk,
>
>
> "Slot 6" might be assigned to loco address 6.? Or loco address 0.? Or loco address 3. or loco addres 2154, or any other loco address between 0 and something over 9900 (but not quite to 9999, with Digitrax systems).? "Slot 6" is NOT NECESSARILY associated with "DCC address 6".? In fact, it typically will not be.
>
> Exact slot assignments depends entirely upon the sequence in which locos are acquired and dispatched/dropped, and the way that various throttles attempt to re-acquire locos when they become powered-up and/or attached to a live LocoNet.
>
> It is generally only possible to know what address is associated with "Slot 6" when some LocoNet agent "queries" the command station for "slot 6" information.? JMRI can perform that function, as part of the LocoNet "Slot Monitor".? See .
>
> To interpret that tool's results when you use the tool, you need to reference the "slot number" that you see in LocoNet Monitor in the left-most "Slot" column of the tool's table - in your case, look for the row for "Slot" number 6.? Then look at that row's "Address" column to determine the address assigned to the slot.? Once you know that address, try to dial that address on a live throttle.? You will likely get the "Steal" message (or some LED color indication on those throttles which cannot display alphanumeric information).
>
> In the image at the top of the above-referenced web page, slot 6 just so happens to be assigned to address 6.? (This is not typically what users see, unless they just happen to acquire locos of particular numbers in a particular order from a command station with a particularly-clean slot table.)
>
> This assignment of address 6 to slot 6 just happens to be coincidental, and this coincidence is likely because the JMRI developer who created the image did not use much imagination (or realism!) when "acquiring" locomotives before creating the image...? Perhaps that image needs to be updated to show a more-typical situation where random addresses were acquired, rather than sequential addresses.
>
> Regards,
> Billybob
>
>
>
>
>
>
>
>
--
Bob Jacobsen
rgj1927@...
|
Bob Jacobsen