Closed pabender closed 3 years ago
On Nov 17, 2018, at 1:06 PM, Paul Bender notifications@github.com wrote:
But if I dispatch it from the iPhone it disappears from the active slot monitor and the WiThrottle server. I cannot then reacquire the loco through the WiThrottle app.It appears to work on the app - the loconet monitor shows a response to the throttle changing but the loco does not respond.
Dispatch is a process that has very little use currently and I personally have never used it for its intended purpose. Certain older Digitrax throttles (anyone still have a DT100?) could not select a 4-digit address but were able to control any slot. The brief description is you could select a 4-digit on a capable throttle, then “dispatch” it to slot-0. I forget exactly what you do on the 2-digit only throttle, but it could then retrieve that loco control from slot-0 (or it sent commands to slot-0). A LN throttle uses the slot number for control, not the decoder address.
Probably the easiest way to fix this issue is for me to remove “dispatch” from WiThrottle, which I am planning for the next update. But I am often afraid of affecting the one user who may be still using it! (Of course, it is still in JMRI.)
Regards, Brett
Dispatch is commonly used in module meetings, for example Fremo meetings.
There is a special LocoNet throttle, the Fred that doesn't have any way to select an address at all, but is total dependent on the dispatch feature. This is per design, since on a big model railroad meeting with several hundreds of meters of railroad and dozens of train drivers running trains at once, there is a huge risk of selecting the wrong engine by mistake. So we use one throttle per engine thrue out of the entire meeting.
Dispatch can be made without the Withrottle, for example by using the Z21 app or by using a JMRI throttle, so it's not necessary to keep that functionality in the withrottle.
But dispatch on LocoNet is used a lot in Europe.
On Nov 17, 2018, at 4:11 PM, Daniel notifications@github.com wrote:
Dispatch can be made without the Withrottle, for example by using the Z21 app or by using a JMRI throttle, so it's not necessary to keep that functionality in the withrottle.
Daniel, Thanks for that insight! So, would it make sense to leave it in? If it is used, it should be there.
Regards, Brett
@BHoffman351, rather than making WiThrottle changes, perhaps it makes sense to wait to see if the current work by @pabender on issues surrounding LocoNet acquire/dispatch/release will solve the WiThrottle-related troubles.
@devel-bobm I wasn’t going to look into the dispatch issues. That is too deep into the LocoNet internals for me to look at now.
@BHoffman351 dispatch is also used on modular layouts in the US to prevent the dreaded “slot max”. I am not sure how much of an issue that will be with layouts running expanded slots, but it certainly is an issue on systems running a DCS100 as the command station.
@danielb987 's comment about "dispatch" use by European modular groups makes me think that WiThrottle "dispatch" may be "nice-to-have" for those layouts. Some of those layouts get incredibly large, so having to find a "capable" throttle, or run to a computer, could be awkward. Those hand-held, portable, do-anything devices sure can be handy, so removing a "little-used feature" may not be the ideal way to go.
Yes, it's very nice to have dispatch in the WiThrottle. So if it's not too much trouble, it would be nice to keep it.
@pabender wrote
dispatch is also used on modular layouts in the US to prevent the dreaded “slot max”.
In this particular use, "Dispatch" is simply one of several possible ways for a throttle to "stop using a loco" cleanly and leave the "slot" in a state where the command station may re-use it for another loco.
When implemented correctly, "Release" is just as good as "Dispatch". The difference is primarily that "Dispatch" allows easy acquisition from a BT2, FRED, or similar "simple" throttle.
(Any discussion of whether JMRI implements LocoNet slot "Dispatch" or LocoNet slot "Release" correctly should be given a new github issue.)
One our meetings where I was running JMRI was a large modular layout at the UK NMRA annual convention in Derby UK with freemo modules including those from Netherlands present. The stealing issue crashed JMRI more than once (I think because JMRI was waiting too long for something to happen). The dispatch issue affected a number of people using phones as throttles where they lost the ability to use their favourite (ie sound with many functions) locos with their phones.
Dispatch works with Digitrax throttles to allow another Digitrax throttle to immediately acquire that loco, and with other throttles as noted here, but is not working with JMRI and WiThrottle.
The temporary remedy for me is to tell everybody to only use release with Withrottle and not to select both in the Withrottle settings. Also stealing is generally a bad idea within Digitrax systems since it allows two throttles to have simultaneous control of a loco (for training or monitoring purposes). The best advice I can give for those wishing to use both Digitrax throttles and phones with the same loco is to ensure that the loco has been released form the Digitrax throttle first ( Loco and then when the number is flashing Exit) before using on their phone.
Thank you all for considering these two loconet problems of stealing and dispatching. I now understand much better how to deal with these.
David Matthews Worcester UK N Gaugers
"Dispatch" is a slot move from a slot to slot zero. eg (BA 02 00 47) slot two to zero. To get the "dispatched" slot a move from slot slot 0 zero is performed (BA 00 00 47) (destination irrelevant). Depending on the command station dispatched slots are either idle or common. The get slot slot zero changes the status to in-use, and sends a slot status message back. (E7 blah) Throttles that only have the ability to get slot zero use this. Only one slot should be dispatched at once, its a LIFO stack one deep. As far as I know JMRI has no get Dispatched slot.
To make the details complete you can "Dispatch" a slot with the expanded slots protocol (D4 39 03 00 00 11) move slot 131 to zero. But can only retrieve it with loconet 1.n message (BA 00 00 47)
@devel-bobm
This May have changed, but the way release was originally implemented on LocoNet was so that it did exactly the same thing as selecting a new address on a handheld throttle without dispatching the old address first. That leaves the slot in use by the throttle ( whether this is JMRI or something else doesn’t matter ). Dispatch was the only method we had to actually give up control of the slot.
On Nov 17, 2018, at 4:25 PM, Bob Milhaupt notifications@github.com wrote:
rather than making WiThrottle changes, perhaps it makes sense to wait to see if the current work by @pabender https://github.com/pabender on issues surrounding LocoNet acquire/dispatch/release will solve the WiThrottle-related troubles.
@devel-bobm https://github.com/devel-bobm The changes that I am making in the WiThrottle app are completely unrelated to any of the discussions on the group. I had never heard of anyone using Dispatch but have had many questions about what it does and why. Now that I have heard of its usage, it will remain!
Regards, Brett
@pabender,
This May have changed, but the way release was originally implemented on LocoNet was so that it did exactly the same thing as selecting a new address on a handheld throttle without dispatching the old address first. That leaves the slot in use by the throttle ( whether this is JMRI or something else doesn’t matter ). Dispatch was the only method we had to actually give up control of the slot.
I do not see the behavior you report when I try the same sequence with equipment I have available to me.
With a DCS100, If I dial up loco 300 on my trusty DT400, run it a bit, then dial up loco 3005 on the same side of that DT400 (without attempting to "dispatch" or "release" loco 300), the slot containing loco 300 is written to a state of "Common" at the moment when the user presses the "Loco" button. This is shown by the [B5 01 17 5C]
message in the log below.
This slot status change is checked at the end of the sequence in the log by manually performing a slot read of the slot containing loco 300. The reported slot data is shown in the final message in the log. In this particular case, the command station has chosen to change the slot state from the requested mode of "Common" to "Idle".
This observed behavior contradicts the quote above, as the slot is not left in the "In Use" state.
[BB 7B 00 3F] Request Fast Clock information.
[E7 0E 7B 04 50 09 00 04 00 00 00 00 00 34] Response Fast Clock is Synchronized, Running, rate is 4:1. Day 0, 00:53. Last set by ID 0x00 0x00 (0).
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available.
[BF 00 00 40] Request slot for loco address 0 (short).
[81 7E] Master is busy.
[E7 0E 01 03 00 00 00 04 00 00 00 00 00 10] Report of slot 1 information:
Loco 0 (short) is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BF 00 03 43] Request slot for loco address 3 (short).
[E7 0E 01 03 03 00 00 04 00 00 00 00 00 13] Report of slot 1 information:
Loco 3 (short) is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BF 00 1E 5E] Request slot for loco address 30 (short).
[E7 0E 01 03 1E 00 00 04 00 00 00 00 00 0E] Report of slot 1 information:
Loco 30 (short) is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BF 02 2C 6E] Request slot for loco address 300.
[E7 0E 01 03 2C 00 00 04 00 02 00 00 00 3E] Report of slot 1 information:
Loco 300 is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BF 02 2C 6E] Request slot for loco address 300.
[E7 0E 01 03 2C 00 00 04 00 02 00 00 00 3E] Report of slot 1 information:
Loco 300 is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BA 01 01 45] Set status of slot 1 to IN_USE.
[E7 0E 01 33 2C 00 00 04 00 02 00 00 00 0E] Report of slot 1 information:
Loco 300 is Not Consisted, In-Use, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[EF 0E 01 37 2C 00 00 04 00 02 00 33 44 75] Write slot 1 information:
Loco 300 is Not Consisted, In-Use, operating in 128 (Allow Adv. consisting) SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x44 0x33 (8755).
[B4 6F 7F 5B] LONG_ACK: Function not implemented, no reply will follow.
[A0 01 02 5C] Set speed of loco in slot 1 to 2.
[A0 01 03 5D] Set speed of loco in slot 1 to 3.
[A0 01 04 5A] Set speed of loco in slot 1 to 4.
[A0 01 05 5B] Set speed of loco in slot 1 to 5.
[A0 01 04 5A] Set speed of loco in slot 1 to 4.
[A0 01 03 5D] Set speed of loco in slot 1 to 3.
[A0 01 02 5C] Set speed of loco in slot 1 to 2.
[A0 01 00 5E] Set speed of loco in slot 1 to 0.
[B5 01 17 5C] Write slot 1 with status value 23 (0x17) - Loco is Not Consisted, Common and operating in 128 (Allow Adv. consisting) speed step mode.
[BF 00 03 43] Request slot for loco address 3 (short).
[E7 0E 02 03 03 00 00 04 00 00 00 00 00 10] Report of slot 2 information:
Loco 3 (short) is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BF 00 1E 5E] Request slot for loco address 30 (short).
[E7 0E 02 03 1E 00 00 04 00 00 00 00 00 0D] Report of slot 2 information:
Loco 30 (short) is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BF 02 2C 6E] Request slot for loco address 300.
[E7 0E 01 27 2C 00 00 04 00 02 00 33 44 6D] Report of slot 1 information:
Loco 300 is Not Consisted, Idle, operating in 128 (Allow Adv. consisting) SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x44 0x33 (8755).
[BF 17 3D 6A] Request slot for loco address 3005.
[E7 0E 02 03 3D 00 00 04 00 17 00 00 00 39] Report of slot 2 information:
Loco 3005 is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BF 17 3D 6A] Request slot for loco address 3005.
[E7 0E 02 03 3D 00 00 04 00 17 00 00 00 39] Report of slot 2 information:
Loco 3005 is Not Consisted, Free, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BA 02 02 45] Set status of slot 2 to IN_USE.
[E7 0E 02 33 3D 00 00 04 00 17 00 00 00 09] Report of slot 2 information:
Loco 3005 is Not Consisted, In-Use, operating in 128 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[EF 0E 02 37 3D 00 00 04 00 17 00 33 44 72] Write slot 2 information:
Loco 3005 is Not Consisted, In-Use, operating in 128 (Allow Adv. consisting) SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x44 0x33 (8755).
[B4 6F 7F 5B] LONG_ACK: Function not implemented, no reply will follow.
[BB 77 00 33] Request data/status for slot 119.
[E7 0E 77 00 00 00 00 04 00 00 00 00 00 65] Report of slot 119 information:
Loco 0 (short) is Not Consisted, Free, operating in 28 SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0).
[BB 01 00 45] Request data/status for slot 1.
[E7 0E 01 27 2C 00 00 04 00 02 00 33 44 6D] Report of slot 1 information:
Loco 300 is Not Consisted, Idle, operating in 128 (Allow Adv. consisting) SS mode, and is moving Forward at speed 0,
F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off
Master supports LocoNet 1.1; Track Status: Off/Paused; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x44 0x33 (8755).
I have confirmed the same behavior on a DCS240 and on a DB150.
Be aware that LocoNet Slot Monitor is not always a good judge of the actual slot state. The only way to know the actual slot status is to query the slot status! Older code was not sensitive to LocoNet messages which can influence the actual slot state; newer code attempts to track slot state for those LocoNet messages which are known to update slot state in consistent ways. And (as shown in the log above), the command station can choose to change the slot state without any notification via LocoNet!
The LocoNet Slot Monitor has a mechanism to occasionally request the slot data (something like every 600 seconds unless other LocoNet message activity provides concrete slot info), so eventually, it will show the right info, at least for a given moment in time.
If I try another experiment and throw another throttle into the mix (i.e. one which has "stolen" the slot), the slot status is modified in the same way as for the single-throttle case. If I have a loco acquired and active, and then press the "Loco" button while that loco is active on the throttle, the throttle immediately sends a LocoNet message to change the slot state to "Common". It doesn't matter if the throttle was the original one which acquired the loco or a following throttle which had to "steal" to get control; the throttle simply sends the LocoNet message to change the slot state to "Common".
Please keep in mind "Virtual Sound Decoder". This application will not run without the Dispatch functionality.
@klk32003, given the vagueness of the term "Dispatch", and my unfamiliarity with VSD, please expand on your statement:
Please keep in mind "Virtual Sound Decoder". This application will not run without the Dispatch functionality.
How does VSD use "Dispatch", and how does VSD fail if "Dispatch" is not available? Are you concerned about "LocoNet Dispatch" or "JMRI Throttle 'Dispatch'" or some other form of "Dispatch"?
On Nov 18, 2018, at 4:30 AM, klk32003 notifications@github.com wrote: Please keep in mind "Virtual Sound Decoder". This application will not run without the Dispatch functionality.
VSD doesn’t actually require the dispatch function.
VSD requires the ability to listen to throttles. In the General case ( not specifically LocoNet ) it isn’t always possible for us to listen to the system specific throttles.
It is always possible for JMRI to listen to its own throttles ( On Screen throttles, WIThrottle, Scripts, etc ).
In the LocoNet specific case, working with system specific throttles relies on sharing. Digitrax May have broken the ability to use this with expanded slots...
@devel-bobm Thanks for asking ... First note: I have no feedback from other VSD users, so the following is my own experience. Second note: there is no issue with a JMRI throttle and VSD.
I use "Dispatch" before I add a "VSDecoder". I open a JMRI throttle, set the DCC address which is also assigned to my LocoNet throttle (I use a FRED). When the "steal" question appears (this isn't the case for the first JMRI session), I confirm with "yes". Then I click on "Dispatch" and close the JMRI throttle. Next step is to add a VSDecoder. VSD does a x.setLocoAddress(locoaddress) and attach a listener to the throttle. Now I can run a train and plug-out and plug-in my FRED as I follow the train along my modular layout.
Before the LocoNet Steal was implemented, there was no need of a "Dispatch" step, of course.
When I skip the "Dispatch" step, the DCC address of my FRED will be deleted.
I don't use Digitrax hardware. My DDC system is a Intellibox I, my throttles are DIY devices, transponding is generated by a RailCom device, and my DCC decoders are from ZIMO or LENZ.
On Nov 18, 2018, at 8:10 AM, klk32003 notifications@github.com wrote: @devel-bobm Thanks for asking ... I use "Dispatch" before I add a "VSDecoder". I open a JMRI throttle, set the DCC address which is also assigned to my LocoNet throttle (I use a FRED). When the "steal" question appears (this isn't the
case for the first JMRI session), I confirm with "yes". Then I click on "Dispatch" and close the JMRI throttle. Next step is to add a VSDecoder. VSD does a x.setLocoAddress(locoaddress) and attach a listener to the throttle. Now I can run a train and plug-out and plug-in my FRED as I follow the train along my modular layout.
Before the LocoNet Steal was implemented, there was no need of a "Dispatch" step, of course.
VSD SHOULD be doing ( internally ) an automatic steal, which SHOULD result in sharing the slot with your FRED. It is also possible for us to bring the steal out for the user to decide, since VSD has a UI associated with it.... When I skip the "Dispatch" step, the DCC address of my FRED will be deleted.
That sounds like the FRED is only using the dispatch slot.
Question: Can you use more than one FRED on a layout at a time?
I ask because it sounds like the FRED is using the address in the dispatch slot without moving it to another slot. If that is the case, you would only be able to use one FRED at a time.
The dispatch step isn’t required for any of the Digitrax throttles I have used with VSD. I don’t even bring up a JMRI throttle if I am using any of the LocoNet throttles I have for control.
If you are using a Digitrax Evolution Command Station you will need to start the vsd before acquiring on a Digitrax Throttle which would be a steal but JMRI doesn't care. This applies regardless of version of Loconet protocol being used. This is one of a few cases where a read only throttle would be nice.
Question: Can you use more than one FRED on a layout at a time?
To be sure I updated my local repository (git pull). I can run two locos with two FREDs on my layout. I can run two locos with JMRI and two JMRI throttles on my layout. But I can't run two locos with JMRI and two FREDs and VSD on my layout. That's new for me. Also new is a NPE when I want to start a loco.
I followed @Pugwash1 's strategy, starting VSD before aquiring on a FRED throttle: no Steal offer, but DCC address is deleted on FRED.
Sorry, I need some time to understand ...
@klk32003 Those instructions work when using a real digitrax throttle & command station with VSD, I dont know how the Intellibox reacts. The VSD actually does the correct thing and asks for a throttlelistener, not a throttle, the implementation of attachlistener does the createthrottle that goes wrong when a throttle doesnt exist and is already in use, so if the JMRI throttle is created first, then the vsd applied and then FRED. You may have to clear all the slots on the command station between tries.
@pabender wrote:
In the LocoNet specific case, working with system specific throttles relies on sharing.
LocoNet itself does not require that JMRI create a throttle in order to "snoop" another throttle's activity. That is a purely the way JMRI behaves for LocoNet connections, as it handles both the case of a "passive listener" and a "listener and active controller".
JMRI does not differentiate between "creating a JMRI throttle in order to control a loco" and "creating a throttle in order to monitor a loco". JMRI does not offer (so far as I can tell) the coder an option to "listen on LocoNet to a specific loco's activities" without creating a JMRI throttle.
Here's a blue-sky idea: JMRI's protocols could be extended to allow for a "listen-only" interface to a loco. This would be in addition to the existing mechanism that allows both "passive listening" and "listening with active control" when using LocoNet "standard" slots.
For LocoNet connections, this extension would implement a "loco listener", something like a "slot listener", but without any ability to modify any slot contents and without any need to "acquire" the LocoNet slot. This type of extension would specifically be useful for VSD with LocoNet systems, since VSD does not need to control the loco.
When working with LocoNet connections, a VSD implementation using such a JMRI protocol extension would simply request a "loco listener"; the LocoNet implementation would inquire to determine the slot number associated with the mobile decoder address without going thru the whole loco acquisition process. Once the slot number was known, the LocoNet implementaiton would simply report any related slot activity to the VSD "loco listener".
I have no knowledge of other system-level protocol architectures so I cannot guess how other systems would or could handle and implement such an interface.
@pabender also wrote:
Digitrax May have broken the ability to use this with expanded slots...
LocoNet Expanded slots will specifically prevent multiple throttles from controlling the same slot (loco). There may be ways to "cheat" around this limitation, but I would prefer that such "cheating" be avoided.
A "non-cheating" JMRI LocoNet expanded slots solution would not be compatible with the existing VSD implementation. The "blue-sky" idea I mention above is one possible way to keep VSD functionality with a "non-cheating" expanded slot implementation.
@devel-bobm : If a read-only throttle is implemented, does that require that JMRI understands the extended slot commands in order to be able to listen on a loco using extended slot?
I have worked with standard slots but have no knowledge about extended slots. Are there any public documentation about this?
@pabender The CreateThrottle already has a boolean for a read only throttle, but is not implemented in Loconet. The VSD doesnt need to change, loconet needs to implement its own AttachListener such that it does a create with readonly if it doesnt already exist. danielb987 Extended slot listen Yes see WIP #5847
I won’t pretend to know all the ins and outs of Slots on Digitrax systems. I do know that we should not make any changes to the interface that 1) puts a burden on the majority of systems we support and 2) breaks any existing tools or scripts that are written to work
Yes, there are provisions for read only throttles in the manager interface. Those are important in some situations.
I do know we have strayed from the issue, which is that dispatch doesn’t currently work correctly for LocoNet systems, and that once a throttle is dispatched, it can’t be re-acquired. That is definitely a bug.
@pabender para 1 , totally agree. Para 2 the vsd needs it. Para 3 will be done. Give me 15mins.
One possible solution on the read only throttle problem can be to have a new interface ReadonlyThrottle. Se PR #6167 for a suggestion. If a system supports read only throttles, a ReadonlyThrottle is supplied. If not, the caller needs to request a Throttle instead.
Sent from my iPad
On Nov 18, 2018, at 5:08 PM, Daniel notifications@github.com wrote:
One possible solution on the read only throttle problem can be to have a new interface ReadonlyThrottle. Se PR #6167 for a suggestion. If a system supports read only throttles, a ReadonlyThrottle is supplied. If not, the caller needs to request a Throttle instead.
I’ll make a couple of comments on that thread PR...
@devel-bobm : If a read-only throttle is implemented, does that require that JMRI understands the extended slot commands in order to be able to listen on a loco using extended slot?
Yes.
I have worked with standard slots but have no knowledge about extended slots. Are there any public documentation about this?
No.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. JMRI is governed by a small group of maintainers which means not all opened issues may receive direct feedback.
This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the maintainers may elect to reopen this issue at a later date if deemed necessary.
I have experimented today and I realise there is also a problem also with dispatching.
So I started with the DCS100 with its memory reset and a MacBookPro using JMRI 4.12 and Locobuffer. I ran Withrottle on my iPhone. The JMRI slot monitor showed no slots selected. I selected loco 2201 on the iPhone app. All was well and it showed up in the loconet monitor and the slot monitor. I then released it on the iPhone and it disappeared from the WiThrottle server and the slot monitor. It can then be reselected on the iPhone and all is well.
But if I dispatch it from the iPhone it disappears from the active slot monitor and the WiThrottle server. I cannot then reacquire the loco through the WiThrottle app.It appears to work on the app - the loconet monitor shows a response to the throttle changing but the loco does not respond. I can acquire it and release it using a Digitrax throttle. But whatever I do with the WiThrottle app shows up in loconet monitor and the WiThrottle server but not in the slot monitor and the loco does not move. This is not stealing. I cannot then use this loco on the Withrottle app again until JMRI is rebooted.
The system console does not show an error, unless the following is a clue:
WARN - current stored duration is not a valid number "null" [thread 20]
I hope this helpful.
David Matthews
Originally posted by @bunnshill in https://github.com/JMRI/JMRI/issues/6144#issuecomment-439628290