开云体育

Sorry, I forgot to add 1 thing. MAYBE, when the decoder reading failed, there was a noticeable delay between clicking on the "Read type from decoder" button, and anything happening on the MXULFA /

I have done some testing, using JMRI 5.10 and my Zimo MXULFA v0.84.93, on a Linux laptop. I was able to reproduce what I believe to be the same symptoms as Jonas. I had my MXULFA connected to a Zimo

I built my own, just for a bit of fun really, but I like it and continued to use it. Just a few knobs off Amazon, an ESP32 and whatever you can do to put a case around it. I made a video about it,

Hi Chris, This issue is normally related to Window Frames which can have the "Always on Top" property set. The JMRI System Console is a handy Frame in this regard to test Dialogs with /

Tony, I second Steve's suggestion Instead, I'd strongly suggest turning on the TRACE logging for jmri.jmrit.dispatcher and carefully read through that output. I've used traces and it was very

I believe this might be the documentation that describes the communication protocol for the MXULF.? I can't help with the coding side of things, but I can assist (if required) with testing. From my

In order to solve the problem we probably need documentation about the protocol that is used for the communication between the MXULF and the computer. I have found the device on the Internet but I

But DO NOT think "clearing the slots" will solve the problem!!!! "Clearing the slots" is something that affects the command station, But it almost _never_ does anything to address the problem: the

Thanks Dave, I will take a look. I had not explored routes before as I had, perhaps wrongly, assumed that the turnout settings would need to make logical sense as a route which, at startup (perhaps

And since you are already in a Digitraxx profile, open the slot monitor to see which slots have which addresses set, and clear out any leftovers. -- --- Thomas DeSoto, TX

and from experience, lots of script changes happened between those releases. So starting with an old JMRI version can cause LOTS of issues later. Keeping up with the current release may seem hassle,

If the same hardware works correctly with different software, then it is pointing to a bug in JMRI. So, raise a bug report, and you're probably hoping that a developer will work with you to identify

Sorry, I don't think you see the log on my previous picture.... From PC Seq 163 (S) Prim to/from CS (MX1) Read CV Loco: 0 DCC CV: 1 From CS Seq 125 (S) Ack/Reply 1 to/from CS (MX1) Prog CV From PC

Nick, For your turnouts, you might look at using a Route instead of LogixNG. It is designed to set a group of turnouts with a delay between each one. You can use LogixNG to trigger the route. Dave

Hi Daniel, I think I understand now. In my mind, I was over-simplifying the "single thread" idea.? So was thinking that the "Execute A after......" would block the thread for ten seconds, then

Hi Nigel I can read all type of decoder with DCC setting with ZSP and if I repeat it, the value will be the same. If read tree times CV1 I get three different result and the last one is OK the

All jumpers on the NCE-USB gives you the widest range of supported commands and runs at 19,200 baud. Some of the other ones tell JMRI that it can't do this or that. Getting the right match matters.

Robert, Back in the days before Profiles, the command line was the trick. At one time my desktop had 20-30 different PanelPro icons, one for each layout I worked on. I think it is still there.

Nick, The problem with your solution is that the action "Execute A after 10 seconds" does not stop the ConditionalNG. The ConditionalNG continues to run and stops as soon as all the actions are

Just curious, but why are you using a version of JMRI that's 3.5 years old? There have been half a dozen newer production versions since then... Steve "Breezlys"