Locked
Re: Setting serial port speed for CMRI connection to JMRI
Jerry,
Yes, having dead nodes in the list will kill the response time. It is
waiting and timing out for each of those. I wrote a script to enable/disable
polling per node, but now I think it is in the config page for the node.
Telling it to not bother what isn't there will make a world of difference.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Similar experience with NCE Power Pro (except the PTB-100 is now
powered from the NCE's 16VAC main power supply). <<<< That has been my experience, too. Best regards, Steve Steve Haas Snoqualmie, WA
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
I think Ken may have hit on the answer, although I¡¯ll have to do some more work to prove it. ?I had defined four CMRI nodes to JMRI but only hooked up two so far. ?I did this so I could define their sensors and lights into the JMRI tables. ?But from what you said, that is likely the culprit.
The results of polling of the two connected boards is fine, with results showing up in the sensors table as expected and no extra initialization messages. ?But JMRI is still polling the third and fourth boards and presumably waiting until they?time out (.25 second each?).
I¡¯ll hook up the other boards this weekend and see what happens then, but this may be what is causing the seemingly long time for JMRI to come back around to polling the active boards. ? Thanks for helping think this through.
Jerry
___________________________________
jerryg2003@...
|
Locked
Re: JMRI with C/MRI response times
I've not measured the local CMRI layout to see what the timing is since
we've not had any problems. Last time I was doing any real measuring was for
Dr Chubb and I was focused on the difference of USB vs native serial ports.
That was about 10 years ago and right now I'm not sure of the details. I'd
have to take new measurements.
One thing I'm suspect of is the normal loop timing in an Arduino board. They
make it very easy to add delays and timeouts for many things as you code.
How that impacts the serial port response could also impact the whole CMRI
bus. But I've not got any of those at hand, only the OP has those and we are
relating what he is seeing vs 'normal' CMRI-JMRI interaction times.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
Hi David,
my website is in Czech language, but it is simple and easily translateable by google
connection DR5000 to JMRI it is very good command station with S88 bus and extended signal packets
occupancy detector S88 DIY
Arduino feedback S88 DIY
signal Arduino decoder up to 32 aspects with extended packet
the same decoder for mode simply command stations for matrix commands ?
--
Petr ?¨ªdlo
Czech Republic
|
Locked
Re: JMRI with C/MRI response times
You¡¯re assuming that thread is about normal behavior. It¡¯s not. That¡¯s why the question was being asked. JMRI only a reasonable PC will issue about 50-100 polls a second. Most of the delay is in node-response time and USB delays; JMRI itself takes about 1-2msec to get to the next poll (it deliberately waits a little time to see if the poll¡¯s data generated any output it should send) For 10 nodes, that¡¯s about 5-10 polls a second, and there¡¯s little visible delay. As to complexity: On one very-large layout where JMRI replaced a BASIC program, the polling rate went _up_ with the conversion; JMRI reacted significantly faster after each poll. JMRI doesn¡¯t recompute everything after every poll, only what was needed due to the changes that came in the data. Most of the time, nothing changes, and what looks like complexity to BASIC programmers turns into speed. Certainly, different people have different hobbies. Some like to write their own one-off BASIC, and that¡¯s great. Several people have made improving JMRI¡¯s C/MRI support part of their hobby, and the result of that work has been benefit to everybody who uses it. Bob On Jan 10, 2019, at 9:04 AM, Don Weigt <dweigt47@...> wrote:
I find it hard to believe JMRI used with C/MRI is useful if it runs that slowly. It seems useless for things like scanning control panel switches and such. If that ~ 1 second cycle is to read all input data, it's too slow. If it's for each byte? Yikes!
As I recall, C/MRI boards simply respond when polled. That should be quite fast. What's causing the delay? Is C/MRI still running in BASIC? Is JMRI so complex it's slow?
My home brew I/O cycles through all inputs and outputs in less than 250 ms. Any slower becomes very annoying. I have 8 bytes of photodetector input data, and 16 of turnout position. These need to be read frequently, or they will lag too much.
My railroad as formerly built also had about 25 output bytes. They only need to be written to for initializing and when an output changes. But, the outputting needs to be fast, or it will delay the inputting too much.
What is realistic response time for driving signals and turnouts, and reading turnout positions and occupancy detectors? Is it really several seconds, or even longer? -- Bob Jacobsen rgj1927@...
|
Locked
Re: CV-18 debate CLOSED !!
You need to have at least been given a genuine copy of the 4004 pre-production spec for evaluation directly from Intel to be a fully paid up micro controller pioneer. :) Andy On 1/10/2019 7:06 AM, Nick via Groups.Io wrote: Friends,
I have been a member of this group from the beginning. I have always been proud and happy to help whenever possible. Recently, I made a post about programming using CV 18 to create a 4-digit address with NO information about the system, interface, or the method.
I suggested a method I learned from Loy Spurlock of Loy's Toys back in 1993 using a Digitrax system with a DCS100 and a throttle.
Evidently, this suggestion was considered to be the same as reporting a flying saucer or flying monkeys .
To those members that do not know me, I apologize that you do not understand I try not to spread bad info that I have not tried and I do not make it a habit of misleading people . True, I did not think about folks that have never experimented with new technology , nor did I think I would need to provide "proof" as most member know my "reputation" , such as it is.
I truly apologize that I might have predicted the end of the world, or the possibility that the Earth is not the center of the universe. To those that I have "offended", I apologize and I will no longer attempt to assist someone on-list. For anyone interested, I have the almost 30 year-old documentation from Loy's Toys stored in my shed along with my Atari Computer with a hard drive (I was told, that couldn't be done either). I'm not going to dig it out but I have learned a lesson today that I will not forget. Accusations without investigations help no one. To be quite frank, I honestly do not care if you believe me or not.
Respectfully,
Nick Kulp
--- This email has been checked for viruses by AVG.
|
Locked
JMRI with C/MRI response times
From the topic Setting serial port speed for CMRI connection to JMRI From: Ken CameronDate: Thu, 10 Jan 2019 08:11:39 EST Jerry, Keep in mind that JMRI will poll a node then give it time to reply. Then it gets that reply or times out before polling the next node. So how fast each node responds adds up quick. Use the Command Monitor under CMRI to watch the traffic and do your timings. I would take a sample to a file for 10-20 seconds. Then using Excel I'd process it and compute the delays and specifically look for how much any single delay varies. So if a given node usually replying in 50mSec but every now and then 300mSec, I'd be curious why. -Ken Cameron, Member JMRI Dev Team I find it hard to believe JMRI used with C/MRI is useful if it runs that slowly. It seems useless for things like scanning control panel switches and such. If that ~ 1 second cycle is to read all input data, it's too slow. If it's for each byte? Yikes! ?
As I recall, C/MRI boards simply respond when polled. That should be quite fast. What's causing the delay? Is C/MRI still running in BASIC? Is JMRI so complex it's slow?
?
My home brew I/O cycles through all inputs and outputs in less than 250 ms. Any slower becomes very annoying. I have 8 bytes of photodetector input data, and 16 of turnout position. These need to be read frequently, or they will lag too much. My railroad as formerly built also had about 25 output bytes. They only need to be written to for initializing and when an output changes. But, the outputting needs to be fast, or it will delay the inputting too much. What is realistic response time for driving signals and turnouts, and reading turnout positions and occupancy detectors? Is it really several seconds, or even longer?
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
Many thanks for all this explination.
I'm in Manchester so if they are around there would be awesome.
Will also check out their website. Thanks
|
Locked
Re: CV-18 debate CLOSED !!
It took several happenings, but I've learned to wait at least 24 hours before submitting a blast. Seems that some of our members could have used the same caution.
As he admits in his last, Nick sent a half-vast solution that works in some cases, but neglected to specify when it will or won't. He got responses, more or less emphatic, warning everybody not to try it. Then Nick got all upset because he was called out for incomplete information, and he threatens to stop helping forever.
I think this site would be more fun if all concerned had applied the 24-hour rule.
DrJolS
On Thursday, January 10, 2019, 11:28:43 AM EST, dick bronson <dick@...> wrote:
Nick,
Wait! What do you mean saying the earth is not the center of the
universe?
Dick :)
On 1/10/2019 10:06 AM, Nick via
Groups.Io wrote:
Friends,
I have been a member of this group from the beginning. I have
always been proud and happy to help whenever possible. Recently, I
made a post about programming using CV 18 to create a 4-digit
address with NO information about the system, interface, or the
method.?
I suggested a method I learned from Loy Spurlock of Loy's Toys
back in 1993 using a Digitrax system with a DCS100 and a
throttle.?
Evidently, this suggestion was considered to be the same as
reporting a flying saucer or flying monkeys .
To those members that do not know me, I apologize that you do not
understand I try not to spread bad info that I have not tried and
I do not make it a habit of misleading people . True, I did not
think about folks that have never experimented with new technology
, nor did I think I would need to provide "proof" as most member
know my "reputation" , such as it is.
I truly apologize that I might have predicted the end of the
world, or the possibility that the Earth is not the center of the
universe. To those that I have "offended", I apologize and I will
no longer attempt to assist someone on-list. For anyone
interested, I have the almost 30 year-old documentation from Loy's
Toys stored in my shed along with my Atari Computer with a hard
drive (I was told, that couldn't be done either). I'm not going to
dig it out but I have learned a lesson today that I will not
forget. Accusations without investigations help no one. To be
quite frank, I honestly do not care if you believe me or not.
Respectfully,
Nick Kulp
|
Locked
Re: CV-18 debate CLOSED !!
Nick,
Wait! What do you mean saying the earth is not the center of the
universe?
Dick :)
On 1/10/2019 10:06 AM, Nick via
Groups.Io wrote:
toggle quoted message
Show quoted text
Friends,
I have been a member of this group from the beginning. I have
always been proud and happy to help whenever possible. Recently, I
made a post about programming using CV 18 to create a 4-digit
address with NO information about the system, interface, or the
method.?
I suggested a method I learned from Loy Spurlock of Loy's Toys
back in 1993 using a Digitrax system with a DCS100 and a
throttle.?
Evidently, this suggestion was considered to be the same as
reporting a flying saucer or flying monkeys .
To those members that do not know me, I apologize that you do not
understand I try not to spread bad info that I have not tried and
I do not make it a habit of misleading people . True, I did not
think about folks that have never experimented with new technology
, nor did I think I would need to provide "proof" as most member
know my "reputation" , such as it is.
I truly apologize that I might have predicted the end of the
world, or the possibility that the Earth is not the center of the
universe. To those that I have "offended", I apologize and I will
no longer attempt to assist someone on-list. For anyone
interested, I have the almost 30 year-old documentation from Loy's
Toys stored in my shed along with my Atari Computer with a hard
drive (I was told, that couldn't be done either). I'm not going to
dig it out but I have learned a lesson today that I will not
forget. Accusations without investigations help no one. To be
quite frank, I honestly do not care if you believe me or not.
Respectfully,
Nick Kulp
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
Hi David
Where in the UK are you? If there's a Local Area group of MERG near you I could get you in touch with them. Alternatively, you could have a look at and you should find the contact details for the various Area Group leaders. I too joined MERG for the financial advantage about four years ago and I haven't regretted it one bit. The MERG Forum is every bit as lively as this and you will get answers to any questions you pose very quickly but don't be surprised if you get answers pointing in different directions!
If you are wondering what CAN is it's Controller Area Network, the sort of network that makes everything in your car work. Modules connected to say track circuit detectors send out a message when a block becomes occupied and that can travel along the CBUS pair and 0V to the CANUSB4 that can send the messages via USB to your PC or Raspberry Pi running JMRI. JMRI can then indicate occupation of the track and set the signals behind to their correct aspects. When you click on a turnout (point) the message will go back out by USB to the USB4 and be converted into a CBUS message that then tells a module to move the servo controlling the point to the other position. I think that's the sort of thing you are looking for.
Cheers
Fraser
|
Locked
Re: CV-18 debate CLOSED !!
Nick, First I wish to publically apologize if I have offended you. Please forgive me.? I sometimes get vehement in my opinions when I dont fully understand something. This is supposed to be fun and I particularly relish the wealth of knowledge and sharing of that knowledge that goes on here.? If I deflated some of the fun factor for you or anyone, I deeply regret it.? I too learned something. I need to be more careful with my statements and ask questions of clarifying information rather than pounding out 'facts' as I see them.? You no doubt have years of experience and knowledge that helps others that far exceeds anything I can contribute and I will be more careful in the future. Please reconsider your withdrawal from posting helps. I read all the posts that come through here to try to become more familiar with this aspect of the hobby and I am familiar with your name and know I have benefitted from yours and everyones posts. I too am just an old guy playing with trains. This hobby needs people who are excited and who help each other and are willing to share their knowledge. Not people who squelch creativity and put down people or ideas. That was never my intent.
Respectfully and regretfully, Tom Wilson
Colorado Springs, CO
Friends,
I have been a member of this group from the beginning. I have always been proud and happy to help whenever possible. Recently, I made a post about programming using CV 18 to create a 4-digit address with NO information about the system, interface, or the method.?
I suggested a method I learned from Loy Spurlock of Loy's Toys back in 1993 using a Digitrax system with a DCS100 and a throttle.?
Evidently, this suggestion was considered to be the same as reporting a flying saucer or flying monkeys .
To those members that do not know me, I apologize that you do not understand I try not to spread bad info that I have not tried and I do not make it a habit of misleading people . True, I did not think about folks that have never experimented with new technology , nor did I think I would need to provide "proof" as most member know my "reputation" , such as it is.
I truly apologize that I might have predicted the end of the world, or the possibility that the Earth is not the center of the universe. To those that I have "offended", I apologize and I will no longer attempt to assist someone on-list. For anyone interested, I have the almost 30 year-old documentation from Loy's Toys stored in my shed along with my Atari Computer with a hard drive (I was told, that couldn't be done either). I'm not going to dig it out but I have learned a lesson today that I will not forget. Accusations without investigations help no one. To be quite frank, I honestly do not care if you believe me or not.
Respectfully,
Nick Kulp
|
Locked
Re: Programming locos with Fleischmann Twin-Center sw ver. 2.000 and DecoderPro 4.14
This very much could be a timing error. That¡¯s not completely consistent with what you¡¯re hearing and seeing, but it might be a start. Could you do the following, please? *) Open the LocoNet Monitor *) Make sure ¡°Show Raw Data¡± and ¡°Show Timestamps¡± are checked. *) Click clear screen, do a CV read from JMRI, and then once the timeout error happens, click Freeze Screen (to keep anything from changing) *) Copy and paste the trace to a post here. I can look at the timing to (possibly) see what¡¯s going on. Also, when you read a CV from the Twin-Center keypad, does anything appear on the LocoNet monitor? If so, I¡¯d like a copy of that too. Bob On Jan 9, 2019, at 10:54 AM, cocco.bill.97@... wrote:
Hello Alan, reading CVs by directly using the keypad on the Twin-Center works as expected. I can hear the relay switching the program track on when I enter programming mode and all basic CVs read and write successfully on different locos.
I did some more testing with JMRI and I noticed that at times the relay clicked some (long) time after I pressed the command to read CVs on the PC but then I got the same timeout error. In this case, after the click, one time I saw the command station crash and reset itself, and another time on the console screen another error message came up regarding an unrecognized incoming loconet package. I'm sorry, in the hurry I forgot to copy-paste it this morning.
My guess would be that for some strange reason the command station takes longer to answer in programming mode when controlled via the serial port and because of this JMRI believes that the request has been lost and sends a new request, eventually hogging the buffer of the serial interface with requests, which would explain the errors broken incoming packages and the crashes on the Twin-Center. This is only my assumption based on what I saw though, I have no knowledge the internal workings of the thing, so if you know something more about it I'll be glad to be corrected.
Thank you, -- Bob Jacobsen rgj1927@...
|
Locked
Re: CV-18 debate CLOSED !!
Nick,
Hey don¡¯t take it so hard!? You have been a great inspiration to many of us during the early years of JMRI, and I for one appreciate your passion for the JMRI project, regardless of current events.?
?
I thank you for your diligence in helping get JMRI ¡°off the ground¡± so to speak.? I (for one) would not be using JMRI were it not for you and others like you.? Your original control panel created in CPE, that you shared with all of us NOOBE¡¯s
?inspired me to do the same, and it works very well.? I can¡¯t thank you enough.
?
And please, continue to assist those in need.? There are many of us, and more are arriving every day if I can believe my e-mails, lol!
?
Atentamente, (Best regards,)
?
Keith E. Williams
Project Director ¨C GM Ramos New Paint Shop
Ramos Arizpe, Mexico
?
+1 678-977-6150
?
|
Locked
Re: Continued ECoS Issues...think I am near a solution. It is the ECoSDetector RC 4 ports
It¡¯s _great_ that you want to make the ECoS support better! There hasn¡¯t been much work on it so far, so I¡¯m sure that code can be improved. Generally, reporters just _report_ exactly what they hear. In this case, that¡¯s just an address. There are a couple of scripts that can take that and reformat it into more useful information, see for example: jython//ReporterOperations.py jython//ReporterFormatter.py We could certainly do something similar for roster entries. Some systems get type information from configuration data, instead of trying to work it out from what¡¯s seen on the link. C/MRI for example requires the JMRI user to configure information about the C/MRI nodes (boards), which includes how many (and in some cases what type) of inputs and outputs are there. In other cases, the JMRI user adds Turnouts and Sensors to tables which are used to construct the polling information. So there are several ways to get things like port count in advance if that¡¯s helpful. But I don¡¯t know enough about the ECoS devices to really suggest which would be best. Bob On Jan 10, 2019, at 4:33 AM, Nathan Tableman <nathan@...> wrote:
I have changed the EcosSensorManager to work (I think) with my 4 port detector. I have to say I am really disappointed here, because the reporter has the address not the roster name - but useful that much. But I know see 4 sensors and 4 reporters.
I don¡¯t know if it breaks the other ESU devices - I might buy one to see.
As software engineer for decades I don't overly criticize others code, so this is more about thinking over a way to flip the code around and instead of using the port count to know which one is Railcom; just take that number and loop/query initial state building a hash of some kind which has the type of each sensor.
I am hunting through the other classes of this type to maybe reuse a model that exists.
Because this is not the only issue: none of the s88 sensors are exposed in JMRI it seems.
I am curious how I am the only/first person to notice both of these.
Nathan
On Jan 9, 2019, at 17:00, Nathan Tableman <nathan@...> wrote:
Setting it up now, I have code I am ready to test¡might need some help making sure I am complying with the community guidelines for submitting it back, but¡here I go¡
Be back soon!
On Jan 9, 2019, at 13:59, Bob Jacobsen <rgj1927@...> wrote:
Not an ECoS expert at all, but happy to work with you on tracking this down.
Can you build & run JMRI from a GitHub branch? If so, I can push a version with a bunch more diagnostics in this area for you to try.
Bob
On Jan 9, 2019, at 3:58 AM, Nathan Tableman <nathan@...> wrote:
This one is making me nuts! So I started reading the code and I think I found the issue (maybe)¡I have these two devices:
ECoS - ECoS 50200
ECoSDetector RC - 50098 which only has four ports
Custom s88 module based on MQTT - unlimited ports (limited to the hard limit) (this doesn¡¯t work in JMRI either, but I am not certain that is ECOS/JMRI or me¡)
iTrain ¡°sees¡± all my ports coming from the ECoS, so I am pretty confident in the statement that this is a JMRI issue.
So I turned on debug on log4j.category.jmri.jmrix.ecos=DEBUG
This is what happens
There are a lot of which I think is related to me not having my turnouts setup right in JMRI, which is my fault...
2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
BUT this seems to be the doozie:
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]
This is the exchange
cmd: queryObjects(26, ports)
rep: <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>
So I have JMRI/java/src/jmri/jmrix/ecos/EcosSensorManager.java open and taking a look a where it might need to be changed locally for me to work¡but before I get too far I wanted to see if anyone else has seen this and has input/solutions/I¡¯m crazy :)
Nathan
ps I am long overdue on posting on my blog all the MQTT work, but my goal is a FULLY MQTT setup.
Details below:
2019-01-09 06:40:52,640 util.Log4JUtil INFO - * JMRI log ** [main]
2019-01-09 06:40:53,911 util.Log4JUtil INFO - This log is appended to file: /Users/ntableman/Library/Preferences/JMRI/log/messages.log [main]
2019-01-09 06:40:53,912 util.Log4JUtil INFO - This log is stored in file: /Users/ntableman/Library/Preferences/JMRI/log/session.log [main]
2019-01-09 06:41:00,282 profile.ProfileManagerDialog INFO - Automatically starting with profile Cmd_Tableman_Rail.3e58af63 after timeout. [AWT-EventQueue-0]
2019-01-09 06:41:00,388 node.NodeIdentity INFO - Using jmri-o_sX5dfJrhNiaaDe7duAwF-3e58af63 as the JMRI Node identity [AWT-EventQueue-0]
2019-01-09 06:41:00,697 ecos.EcosPreferences DEBUG - creating a new EcosPreferences object [main]
2019-01-09 06:41:00,742 ecos.EcosTrafficController DEBUG - creating a new EcosTrafficController object [main]
2019-01-09 06:41:00,747 ecos.EcosLocoAddressManager DEBUG - Waiting for the Ecos preferences to be loaded before loading the loco database on the Ecos [Wait for Preferences to be loaded]
2019-01-09 06:41:00,765 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1, status)>
1 status[STOP]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosPowerManager DEBUG - POWER OFF DETECTED [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(11, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(11, addrext)>
20000 addrext[90g,90r]
20001 addrext[91g,91r]
30000
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,799 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,804 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Found sensor object 200 ports 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]
2019-01-09 06:41:00,816 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,818 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20000,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,819 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000,state)>
20000 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,840 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,850 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000, name1, name2, name3)>
20000 name1["east"]
20000 name2[""]
20000 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20001,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,879 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001,state)>
20001 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001, name1, name2, name3)>
20001 name1["west"]
20001 name2[""]
20001 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:01,489 roster.Roster INFO - Roster rebuilt, stored in /Users/ntableman/Documents/Model-Rail/JMRI/roster.xml [AWT-EventQueue-0]
2019-01-09 06:41:01,515 simpleserver.SimpleServer INFO - JMRI SimpleServer started on port 2048 [AWT-EventQueue-0]
2019-01-09 06:41:01,643 server.WebServer INFO - Starting Web Server on port 12080 [WebServer]
2019-01-09 06:41:01,749 ecos.EcosTrafficController DEBUG - Send a message and wait for the response [Wait for Preferences to be loaded]
2019-01-09 06:41:02,064 server.WebServer INFO - Starting ZeroConfService _http._tcp.local for Web Server with properties {path=/, json=4.1} [WebServer]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(10, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(10, addr, name, protocol)>
1000 name["MRCE 194.640"] addr[1060] protocol[DCC128]
1001 name["BR245 / Traxx DE"] addr[1000] protocol[DCC128]
1002 name["GySEV 1047"] addr[1020] protocol[DCC128]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,281 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,285 json.JsonServer INFO - Starting JSON Server on port 2056 [AWT-EventQueue-0]
2019-01-09 06:41:12,026 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1000, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, speed)>
1000 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, dir)>
1000 dir[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1001, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, speed)>
1001 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, dir)>
1001 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[7])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[8])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1002, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, speed)>
1002 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, dir)>
1002 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,037 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path program: is /Applications/JMRI/ [main]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path preference: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path profile: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path settings: is /Users/ntableman/Library/Preferences/JMRI/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path home: is /Users/ntableman/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path scripts: is /Applications/JMRI/jython/ [main]
2019-01-09 06:44:29,939 mqtt.MqttAdapter WARN - Lost MQTT broker connection... [MQTT Rec: JMRI-MQTT]
2019-01-09 06:44:29,940 mqtt.MqttAdapter INFO - ...trying to reconnect [MQTT Rec: JMRI-MQTT]
--
Bob Jacobsen
rgj1927@...
-- Bob Jacobsen rgj1927@...
|
Locked
Re: JMRI DecoderPro Programmer Format Question
The Advanced format is (with tiny differences in layout to make it all fit better) the Comprehensive format plus an extra Function Labels pane. For more, see and note the info along the left side. The extra pane is described here: Bob On Jan 10, 2019, at 4:09 AM, Bob Morningstar <bobmorning@...> wrote:
When you open up DecoderPro in either ops or service mode and select a loco to work with there is a section at the bottom of the Decoder Pick Tree that says "Programmer Format". There are two selections in that pick list that I have always wondered about: "Advanced" and "Comprehensive". What's the difference? Is one a super set of the other?
Thank you for taking the time to answer one of those JMRI trivia questions that have I always wanted to know the answer to.
-- Bob Jacobsen rgj1927@...
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
Jerry,
How many nodes do you have? As I recall the time from any one node to the
next should stay constant. Meaning the time from the poll reply to the next
poll is fairly constant. What I don't recall is if there is a fixed timeout
per node or not. I didn't think so but it's been a few years since I
analyzed a CMRI network. Also the only ones I've worked on were using SMINI
and USISIC nodes. I've not directly worked with the Arduino based nodes. I
recall there is a timer set before it will either retry a poll or go onto
the next node. I think a valid reply would cancel that timers. But watching
the reply to next poll timing would tell about that.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
Two things to check: *) Mixed in with those polls, does JMRI occasionally resend the initialization message? *) Are changes in the poll data showing up in the sensor table? That long a delay sounds like JMRI isn¡¯t seeing a proper response to the poll. It times out waiting for it (although that timeout is a bit shorter than what you¡¯re seeing), and tries again. Since you¡¯re seeing a reply, it can¡¯t be that it¡¯s completely missing. But check if for the right format and contents. Bob On Jan 10, 2019, at 5:58 AM, JerryG via Groups.Io <jerryg2003@...> wrote:
Thanks for the suggestion Ken. That¡¯s actually more or less what I did. Based on CMRI monitor times, my boards are responding to a poll from JMRI in the range of 100ms. What I¡¯m really asking about is the time till the next poll from JMRI, which is in the range of .8-1.2 seconds. Is that right? I thought JMRI was supposed to poll pretty fast.
-- Bob Jacobsen rgj1927@...
|
Locked
Re: MQTT Connection in JMRI
David,
That is true. I just wanted to point out that JMRI likes that "M2T" to be way in the front, and it does not use it in the "addressing" to the real thing. (L5T123 being thrown only gets accessory 123+ON on the LocoNet connection with the prefix "L5".)
Speed
|
Ken Cameron
Petr ?¨ªdlo
Bob Jacobsen