Lenz and TrainController to Digikeijs?

[Edwin_m]

Looks like my Lenz kit now has an error 57 that won't go away with a new battery and any number of resets.  And I've never been satisfied that if and when I ever get the whole lot working I'll have to mess around with assigning trains in TrainController if I want to drive one manually and have TC track it round the layout.  So rather than trying to salvage it I'm considering upgrading to Digikeijs. 

 

The main reason for me to consider this system is the stated support for Lenz RS feedback.  I have nine LDT RS8 modules and one RS16, and replacing with modules for a different feedback system would cost more than the command station (16-way modules might be cheaper but would involve a lot of re-wiring to group the detection sections in 16s instead of 8s). 

 

Reading various things on here and elsewhere I get the impression the Digikeijs is a bit of a work in progress but that the developer is actually progressing things (unlike Lenz!) so I'd appreciate an update from any users on the following questions:

• Having read the long discussion on here, do the RS8 and RS16 now work reliably with Digikeijs, as long as you get J and K the right way round?  The Digikeijs manual I just dowloaded claims RS isn't implemented yet! 
• Does Digikeijs work reliably with TrainController?  Their website claims compatibility by emulating LocoNet but they aren't on TC's list of compatible systems and the above discussion mentions a previous discussion on TC forum that was deleted as off-topic.  I get the impression Freiwald doesn't want anything to do with this system, so I'm probably not going to get much in the way of support from there if I can't get it to work. 
• If it works, does TC automatically pick up when trains are moved from a handset, without having to have them assigned to the DCC system each time? 
• Will LH100 and wired Multimaus work?  I can't be doing with apps for train control, Multimaus seems the best option for a handheld and I might manage to get the LH100 working too. 
• What about the wifi Multimaus?  Does it need a separate router?

[WIMorrison]

If you look at this version of the manual you will see that RS-Bus is supported - the manual you were looking at is v1.1.1 and the firmware is now on 1.5.0, so even this Dutch version is out of date! (there are several online sites that will translate the pdf to English for you (though the pictures are in English) http://support.digikeijs.com/download/attachments/655416/DR5000%20uitgebreide%20handleiding%20NEDERLANDS%20v1.2.3.pdf?api=v2

 

The manual also shows how to connect with TC, and Dijikeijs is heavily used in Germany with TC9, the LocoNet LBServer and TCP/IP Binary are supported LAN protocols which I use exclusively. I can't answer for how TC works are moved in your question, partly because I don't use TC, preferring iTrain, but mainly I can't answer because I don't understand the question though I do understand your point about Herr Freiwald, he can be somewhat awkward to deal with and it is very much his way or no way (and one of the reasons why I use iTrain and not TC  )

 

The LH100 and WiredMultimaus will work using the Xpressnet Bus as will the wifi version BUT, if you are using the LAN for Loconet then you can't connect to the DR5000 as it only supports one network protocol and if you have Loconet selected then you cannot also select Z21, however, if you connect TC via USB then you can use the wifi Multimaus. I use my wifi Multimaus on my home network through iTrain on my PC which talks using Loconet to the DR500 allowing me to circumvent the network protocol limitation.

 

Hopefully, this helps, though I can't answer one question - sorry but if you can explain what you mean I may be able to answer

Edited September 24, 2018 by WIMorrison

[Edwin_m]

Thanks for that Iain. 

 

The issue you haven't answered is probably one for a TrainController user to answer.  It stems from the fact that TC uses command station commands to track when trains are moving, and can't use track occupancy as the prototype would.  Apparently Lenz doesn't spontaneously tell a connected computer system about train movements initiated from a handset, so TC has to be told separately when a train is assigned to a handset and then has to continuously ask the command station if the train is doing anything.  Freiwald says it is Lenz's fault and Lenz apparently said it would be solved in a long-awaited upgrade, but I believe other software doesn't have this problem with Lenz so there is a workaround available.  I just want to be sure that Digikeijs doesn't have the same problem.  According to the Freiwald documentation other command stations can supply the necessary train information, but as Freiwald doesn't recognise Digikeijs I can't be sure whether it will work. 

[pctrainman]

Hi Edwin , have you thought about using Railcom with TC ? it's what I do on my Lenz system .

[WIMorrison]

Edwin

 

I think I understand what you are saying and the use of Railcom solves the issue for me, and did when I used Lenz and also Roco

 

As soon as I place a loco on the track it is instantly recognised by the CV1 value and this shows in my track panel with the loco ID.

 

Is this what you are referring to? If it is then you will need Railcom compatible detectors such as DR5088RC although I am aware that some users have had issues integrating Railcom properly with TC - one person on here who has managed it is Frederick Dewitt who may be able to help you in this respect.

[melmerby]

Do you mean does TC track trains when they are under control of the handset rather than the computer?

The Lenz system doesn't implement this operation although many others do and you want to know whether the DR5000 does. Is that correct?

 

Keith

 

EDIT I have Lenz 100 system and DR5000 (two of!) but I haven't yet tried the handset with the DR5000 (If you can) I also have loads of RS8s

Edited September 25, 2018 by melmerby

[Edwin_m]

Hi Edwin , have you thought about using Railcom with TC ? it's what I do on my Lenz system .

 

 

Edwin

 

I think I understand what you are saying and the use of Railcom solves the issue for me, and did when I used Lenz and also Roco

 

As soon as I place a loco on the track it is instantly recognised by the CV1 value and this shows in my track panel with the loco ID.

 

Is this what you are referring to? If it is then you will need Railcom compatible detectors such as DR5088RC although I am aware that some users have had issues integrating Railcom properly with TC - one person on here who has managed it is Frederick Dewitt who may be able to help you in this respect.

 

Railcom would indeed do this, but at the cost of replacing most of my sixty-odd RS8 detection sections with Railcom detectors.  Replacing the Lenz with a Digikeijs is probably cheaper, should be easier if the answers to my questions are positive, and also solves the problem that the Lenz has stopped working anyway. 

 

Do you mean does TC track trains when they are under control of the handset rather than the computer?

The Lenz system doesn't implement this operation although many others do and you want to know whether the DR5000 does. Is that correct?

 

Keith

 

EDIT I have Lenz 100 system and DR5000 (two of!) but I haven't yet tried the handset with the DR5000 (If you can) I also have loads of RS8s

Yes correct.  If you get your train IDs moving around on the track diagram when using TC with the Digikeijs, using RS8s not Railcom detectors, then that answers my question in the affirmative!  I saw your travails with RS8s on a previous thread and I'm hoping (for my sake as well as yours!) that it's working well now. 

[NIK]

Thanks for that Iain. 

 

The issue you haven't answered is probably one for a TrainController user to answer.  It stems from the fact that TC uses command station commands to track when trains are moving, and can't use track occupancy as the prototype would.  Apparently Lenz doesn't spontaneously tell a connected computer system about train movements initiated from a handset, so TC has to be told separately when a train is assigned to a handset and then has to continuously ask the command station if the train is doing anything.  Freiwald says it is Lenz's fault and Lenz apparently said it would be solved in a long-awaited upgrade, but I believe other software doesn't have this problem with Lenz so there is a workaround available.  I just want to be sure that Digikeijs doesn't have the same problem.  According to the Freiwald documentation other command stations can supply the necessary train information, but as Freiwald doesn't recognise Digikeijs I can't be sure whether it will work. 

 

Hi,

 

I think Train Controller does use track occupancy or position sensors to track trains around a layout unless Railcom track occupancy sensors are used.

 

I haven't heard of it using sensing DCC speed step commands sent to locos but maybe that is in there as well. Is there an advantage if it does?.

 

 

Regards

 

Nick

Edited September 25, 2018 by NIK

[WIMorrison]

None of the control packages actually tracks the trains around - excepting when the layout has Railcom or BiDiB.

 

They all assume that when Train A leaves Block 1 and something arrives in Block 2 (as indicated by the block occupancy feedbacks) that it is Train A that has arrived in the block given that the programme sent Train A from Block 1 into Block 2.

 

Also none of the packages know where anything is on the layout (unless you have Railcom or BiDiB) when you switch it on and it will assume that everything is where you left it - this is a problem if you move something without using the programme as you need to tell it what you have moved.

 

Most of the packages will synchronise the movement of trains when you move them using the handset if the programme is switched on - but again it is optimistic tracking as they really don’t know where Loco 10 has gone to, all they know is that it left the block it was in and something appeared in the next block and the logic of the layout infers it is Loco 10, ergo it must be Loco 10 - unless of course you have ...

 

I won’t say it again

[Nigelcliffe]

None of the control packages actually tracks the trains around - excepting when the layout has Railcom or BiDiB.

 

They all assume that when Train A leaves Block 1 and something arrives in Block 2 (as indicated by the block occupancy feedbacks) that it is Train A that has arrived in the block given that the programme sent Train A from Block 1 into Block 2.

 

 

Depends what you mean by "none of the control packages actually tracks the train".     Some of them do, at least to my way of thinking, without any form of electronic train identification (RailCom etc.).  

 

Example, and I doubt JMRI is alone, but I know this works as I was demonstrating it years ago at Warley show.   I'm pretty sure that TrainController does exactly the same.   

The layout with occupancy detection devices is described with the Layout Editor in JMRI.  If a train is placed on the track, occupancy shows the presence of "something, unknown".  Now, tell the software the identity of the train in question (eg. "Thomas").   Manually with a real throttle (or even pushing it by hand, which shows the software doesn't need the throttle data), drive the train on the layout, through various turnouts and different blocks to another place.   Because the Layout Editor knows the setting of turnouts, and the connections between blocks, that train's identity will move from block to block, and will still be showing as "Thomas" in the block at the destination.   This will work with multiple trains on the track.    There are some limitations when its possible that either of two trains could be entering a block, though that can be got round if the trains were previously moving (so software knows which way they were previously heading, and assumes this doesn't change), or the block has a direction of working rules assigned to it. 

[Edwin_m]

That's exactly what I would expect it to do, and exactly what the prototype does.  But from a discussion a while back (on here I think) it's not what TrainController does. 

 

Instead, TC will only move a train beween blocks if it sees some indication from the command station that the train is moving towards the block that just got occupied.  For this reason TrainController needs to know which way round a train is and won't report the position of a train that moves after being turned manually (though it will track through return loops etc) until manually advised of the new orientation.  This may be of assistance in TC's "dead reckoning" to locate trains in the absence of widespread detection, but it's a pain for those of us with 100% detection installed.  It's not even possible to force the move of a train description from an adjacent block when a particular block detector goes occupied. 

 

It's possible it's changed recently but I have version 8 and the (rather underwhelming) list of new features for version 9 didn't mention this.

[WIMorrison]

Nigel and Edwin.

 

The programmes do not actually track the train - they cannot track it as they have no way of identifying whether said train is actually where you have told the programme it is. What they use is optimistic tracking using the logical diagram that you have created - they ‘know’ the route you have told the train to take ergo if the train moves it must be following that route.

 

However If a loco is shown as being in Block A and you pick it up and drop it in Block D then the control programme will not know where it is and it will assume it is still in Block A - the programme may be confused that there is no longer indication of occupancy in Block A but it will still show the train as Being in Block A though you have physically moved it - by doing that you have broken the logic. If you have LED lighting or resistor wheelsets then the programme is completely screwed as when you move the loco the track will stills how as occupied due to the current draw of the resistors or LEDs.

 

It is a known issue in layouts that do not use train identification where people move things manually, once you start using control programmes - especially on a complex layout - you need to use them to control the layout or be prepared to correct the information to repair the logic that you break by moving something outside the control of the product.

 

A bit like your wife moving the car without telling you she has moved it. You then go out to get in and find it isn’t there but logically it is as no-one has told you it has moved and until you are told the new location you can not operate the car

[melmerby]

I think what Edwin is trying to determine is whether Train Controller will follow a train when under handset control, the same way it does when using an on-screen throttle.

As I understand it the loco control information in some systems is passed from the handset to TC so that it knows what is going on and can calculate the moves around the layout.

I.e "Loco Thomas is moving forward" (after having been already assigned to block 1) Then when occupancy is established in block 2 and lost in block 1 it will now show the loco in block 2 and not in block 1.

 

The Lenz system currently cannot do this (but with V 4.0 of the firmware it should)

I believe what is wanted is a definitive answer whether the DR5000 passes the control information to TC, using some sort of hand controller.

 

Cheers

 

Keith

Edited September 25, 2018 by melmerby

[Edwin_m]

I think what Edwin is trying to determine is whether Train Controller will follow a train when under handset control, the same way it does when using an on-screen throttle.

As I understand it the loco control information in some systems is passed from the handset to TC so that it knows what is going on and can calculate the moves around the layout.

I.e "Loco Thomas is moving forward in block 1 " Then when occupancy is established in block 2 it will now show the loco and block 1 wont.

 

The Lenz system currently cannot do this (but with V 4.0 of the firmware it should)

I believe what is wanted is a definitive answer whether the DR5000 passes the control information to TC, using some sort of hand controller.

 

Cheers

 

Keith

Absolutely.  I was about to say the same in a rather less elegant fashion... 

 

If TC knows Thomas's speed profile and the lengths of the blocks then TC is clever enough to move his position to the next block even if neither block is fitted with occupancy detection, based on what speed and direction have been commanded and for how long.  I can see the benefit of that, but not if I have to remember to assign Thomas to the handset each time.  It's also incompatible with decoder-based inertia settings and with dirty track! 

[WIMorrison]

What you are trying to achieve isn't in this case a function of the command station or handset it is a function of the protocol used between the command station and the controlling programme and whether that programme can use the information provided across the protocol.

I use LocoNet between the DR5000 and my programme (iTrain) understands when I move something using the DR5000 (assuming manual control is permitted for said loco or train) and will track the loco/train correctly as it progresses around the logic diagram (the layout). It also gets confirmation via Railcom that the loco/train is where it optimistically thinks that the train/loco should be.

I have now tried the Lenz xXpressNet Protocol and find that whilst I can drive the trains outside of the control program and they will run correctly I do not get feedback information from the track. I also tried the Z21 Roco/ WLANMaus (a version of Xpressnet) and that worked giving me feedback on the control programme when using and external handset (as expected as I also have a Z21 )

 

The most satisfactory though was LocoNet as this supports the Railcom information that is available fully keeping the layout plan in complete sync with the locos wherever they are. I also switched off Railcom which meant I lost the loco ID and the programme was able to 'track' the loco all the way around the layout - I say 'track' but it wasn't really tracking, it was assuming that because it knows the speed and direction then a loco appears in the next block, it must be the loco that left the last block.

 

For fun I have section which isn't monitored and I stopped an OBB Railbus in that section (Railcom switched off), then took that OBB railbus off the track and swapped it for another loco. I then restarted the loco and when it reappeared it was described as the original OBB Railbus despite actually being an 0-6-2 Zillertal steam tank. I then switched Railcom back on - still driving manually using a handset and as soon as the loco entered a new block it was correctly identified as the Zillertal loco.

 

The moral is, Loconet is the best protocol between the DR5000 and the command programme - ASSUMING you are using a LAN and ytour chosen command programme support LocoNet LB Server or LocoNet Binary. This communication protocol is independent of what bus you use for your occupancy detectors.

Edited September 25, 2018 by WIMorrison

[melmerby]

My next question would be: Is there a cabled handset that works with the DR5000?

Then: How about connecting all the RS bus kit to the DR5000 and using Loconet protocol to connect the DR5000 to the automation program?

 

Keith

[WIMorrison]

 

You could also use a digitrax handset connected to Loconet T

[melmerby]

The other thing is what is XN+FB? (Expessnet + Feedback?)

Is it any use to get loco info to TC?

 

I found this from Digikeijs on Facebook:

 

XN+FB Bus
-- Added special option "Enable Loco Info broadcast" for WDP ( or other control programs which can handle this. It eliminates the need for the notorious Lenz protocol specific polling for Loco Info.

 

Would TrainController now work as Edwin wants?

 

Keith

Edited

Edited September 25, 2018 by melmerby

[Edwin_m]

What you are trying to achieve isn't in this case a function of the command station or handset it is a function of the protocol used between the command station and the controlling programme and whether that programme can use the information provided across the protocol.

 

I use LocoNet between the DR5000 and my programme (iTrain) understands when I move something using the DR5000 (assuming manual control is permitted for said loco or train) and will track the loco/train correctly as it progresses around the logic diagram (the layout). It also gets confirmation via Railcom that the loco/train is where it optimistically thinks that the train/loco should be.

 

I have now tried the Lenz xXpressNet Protocol and find that whilst I can drive the trains outside of the control program and they will run correctly I do not get feedback information from the track. I also tried the Z21 Roco/ WLANMaus (a version of Xpressnet) and that worked giving me feedback on the control programme when using and external handset (as expected as I also have a Z21 )

 

The most satisfactory though was LocoNet as this supports the Railcom information that is available fully keeping the layout plan in complete sync with the locos wherever they are. I also switched off Railcom which meant I lost the loco ID and the programme was able to 'track' the loco all the way around the layout - I say 'track' but it wasn't really tracking, it was assuming that because it knows the speed and direction then a loco appears in the next block, it must be the loco that left the last block.

 

For fun I have section which isn't monitored and I stopped an OBB Railbus in that section (Railcom switched off), then took that OBB railbus off the track and swapped it for another loco. I then restarted the loco and when it reappeared it was described as the original OBB Railbus despite actually being an 0-6-2 Zillertal steam tank. I then switched Railcom back on - still driving manually using a handset and as soon as the loco entered a new block it was correctly identified as the Zillertal loco.

 

The moral is, Loconet is the best protocol between the DR5000 and the command programme - ASSUMING you are using a LAN and ytour chosen command programme support LocoNet LB Server or LocoNet Binary. This communication protocol is independent of what bus you use for your occupancy detectors.

That is as I guessed would happen.  If the real railway can track a train from Plymouth to Dundee that way then it's good enough for my layout.  I notice Digikeijs recommends the Loconet protocol for use with TrainController.  Why LAN - wouldn't the same work over USB? 

[Edwin_m]

The other thing is what is XN+FB? (Expessnet + Feedback?)

Is it any use to get loco info to TC?

 

I found this from Digikeijs on Facebook:

 

XN+FB Bus

-- Added special option "Enable Loco Info broadcast" for WDP ( or other control programs which can handle this. It eliminates the need for the notorious Lenz protocol specific polling for Loco Info.

 

Would TrainController now work as Edwin wants?

 

Keith

Edited

Is this the Z21 protocol Iain referred to? 

 

At the moment I can't see any reason not to use the Loconet though, in which case this particular compexity doesn't matter.  Assuming it will run Loconet protocol over USB or LAN at the same time as running Xpressnet over the X-bus for the handhelds?  And over wifi for a Multmaus? 

 

I'm getting really confused now...

[WIMorrison]

That is as I guessed would happen.  If the real railway can track a train from Plymouth to Dundee that way then it's good enough for my layout.  I notice Digikeijs recommends the Loconet protocol for use with TrainController.  Why LAN - wouldn't the same work over USB? 

It will work over USB but you won't need to worry about what protocol as it doesn't need to be encapsulated within the TCP/IP protocol that is used on the LAN - in summary, if you not using a LAN but are connecting via USB then you can ignore everything about Loconet/Xpressnet/Z21 as you won't be using them and TC will connect without any issues.

[jamespetts]

 

Looks like my Lenz kit now has an error 57 that won't go away with a new battery and any number of resets.  And I've never been satisfied that if and when I ever get the whole lot working I'll have to mess around with assigning trains in TrainController if I want to drive one manually and have TC track it round the layout.  So rather than trying to salvage it I'm considering upgrading to Digikeijs. 

 

The main reason for me to consider this system is the stated support for Lenz RS feedback.  I have nine LDT RS8 modules and one RS16, and replacing with modules for a different feedback system would cost more than the command station (16-way modules might be cheaper but would involve a lot of re-wiring to group the detection sections in 16s instead of 8s). 

 

Reading various things on here and elsewhere I get the impression the Digikeijs is a bit of a work in progress but that the developer is actually progressing things (unlike Lenz!) so I'd appreciate an update from any users on the following questions:

• Having read the long discussion on here, do the RS8 and RS16 now work reliably with Digikeijs, as long as you get J and K the right way round?  The Digikeijs manual I just dowloaded claims RS isn't implemented yet! 
• Does Digikeijs work reliably with TrainController?  Their website claims compatibility by emulating LocoNet but they aren't on TC's list of compatible systems and the above discussion mentions a previous discussion on TC forum that was deleted as off-topic.  I get the impression Freiwald doesn't want anything to do with this system, so I'm probably not going to get much in the way of support from there if I can't get it to work. 
• If it works, does TC automatically pick up when trains are moved from a handset, without having to have them assigned to the DCC system each time? 
• Will LH100 and wired Multimaus work?  I can't be doing with apps for train control, Multimaus seems the best option for a handheld and I might manage to get the LH100 working too. 
• What about the wifi Multimaus?  Does it need a separate router?

 

 

I have been able to get Traincontroller working with the Digikeijs DR5000: see a video

. I do use RailCom on this small automation test layout. Occasionally for no apparent reason, the DR5000 will freeze and not accept any commands until it is power cycled, but this is fairly rare. Aside from this, it seems to work reliably over USB. I do not think that I have been able to get this to work properly over LAN - especially the RailCom detection, although I have not investigated this in detail. I am using TC9 Gold.

 

I have not investigated how well that this works with a handset as I do not have any handsets - I am aware, however, that there is a "dispatch" function when using LocoNet that allows control to be handed between different controllers (and the computer and controllers). I do not know how well that this works.

 

My own automation test layout uses the LocoNet protocol. The DR5000 being a multi-protocol unit can also communicate with TrainController using the XPressnet protocol - I do not know how well that this works as I have not tried it, since it does not work with RailCom.

 

As to the Digikeijs manual, this is some way behind the latest firmware (make sure that you have upgraded your DR5000), and is sometimes incomplete (I had to work out for myself how the RailCom directional indication works, for example).

 

I hope that this helps.

[melmerby]

 

I have been able to get Traincontroller working with the Digikeijs DR5000: see a video

. I do use RailCom on this small automation test layout. Occasionally for no apparent reason, the DR5000 will freeze and not accept any commands until it is power cycled, but this is fairly rare. Aside from this, it seems to work reliably over USB. I do not think that I have been able to get this to work properly over LAN - especially the RailCom detection, although I have not investigated this in detail. I am using TC9 Gold.

 

I have not investigated how well that this works with a handset as I do not have any handsets - I am aware, however, that there is a "dispatch" function when using LocoNet that allows control to be handed between different controllers (and the computer and controllers). I do not know how well that this works.

 

My own automation test layout uses the LocoNet protocol. The DR5000 being a multi-protocol unit can also communicate with TrainController using the XPressnet protocol - I do not know how well that this works as I have not tried it, since it does not work with RailCom.

 

As to the Digikeijs manual, this is some way behind the latest firmware (make sure that you have upgraded your DR5000), and is sometimes incomplete (I had to work out for myself how the RailCom directional indication works, for example).

 

I hope that this helps.

I am using a DR5000 & a Lenz 100 system on Traincontroller Gold Ver 9 both connected by LAN, currently with Expressnet protocol for both

It works fine although I was have some problems with the set up for updating the DR5000 firmware which, thanks to Iain's help, is now hopefully solved

See here: http://www.rmweb.co.uk/community/index.php?/topic/137348-digikeijs-dr-5000-updating-firmware/

 

Cheers

 

Keith

[melmerby]

A strange thing I have noticed with both the DR5000s I have (one 2.5 years old, one brand new but both on firmware 1.4.7) is that very occasionally they seem to lose the DCC signal(?) whilst still powering the track. e.g. a loco decelerating will stop decelerating and carry on at a fixed speed whilst TC assumes it is coming to a halt. It hadn't happened until recently.

Switching off the DR5000 with the red button has no effect, even though the red light comes on the loco carries on. You have to break the track power completely elsewhere, then the loco stops.

At other times the green & red buttons switch track power on & off as normal!

 

Maybe a glitch in the firmware?

Maybe I should try another version?

 

Keith

[WIMorrison]

Not something I have seen or heard of happening - I suggest that you upgrade to 1.5.0 as start only because it fixes some issues and it may resolve the problem.