JMRI
LCC Config Tool Does Not Show New Firmware Version After Bootloading
After bootloading a module with new firmware, the LCC Network Tree reports the new version. If the Configure Dialog was open for the module before bootloading then the Identification segment does not update to show the new version. Refresh All does not change the display. More...Reboot does not change the display. JMRI must be closed/re-opened to see the new f/w version in the configure dialog.
I have never seen this issue with changing firmware on the RR-CirKits boards. The tree even shows it changing to the bootloader and then back to the new version as the update runs.
Which node, node firmware version and JMRI version was this seen?
It's my own node :)
Yes, as I said, the LCC Network Tree shows the new node firmware.
The issue is in the configure dialog that is open for the node being bootloaded.
When a node reboots, it sends out a Node Initialized message. JMRI and its underlying OpenLCB_Java library see that and reset some caches. But it doesn't reset cached CDI and configuration data values. (This CDI cache is why the window opens so quickly when you open it for a 2nd time) I think this is because it takes a while to read those back in again.
Not sure of the best approach here. Thoughts appreciated.
-
We could force the user to reload by e.g. closing the CDI/CD window and clearing the cache. That'll be a delay, which is unfortunate if nothing has changed. JMRI can't know whether something has changed. Some of the RR-Cirkits nodes use a reboot to put their new configuration into effect, so you end up reseting them a couple times when your developing/debugging a new configuration.
-
We could give the CDI a "reload CDI" button, similar to the existing button that reloads the CD contents. But how would people know when to press it?
-
Or something else I haven't thought of?
The new Tower LCC+Q uses the node reboot to compile the structured list (STL) logic into PLC code. This only affects the three syntax error fields in the CDI. Forcing a reload of the CDI would impact PLC code testing.
Dave Sand
----- Original message ----- From: Bob Jacobsen @.> To: JMRI/JMRI @.> Cc: Subscribed @.***> Subject: Re: [JMRI/JMRI] LCC Config Tool Does Not Show New Firmware Version After Bootloading (Issue #12949) Date: Friday, March 08, 2024 5:20 PM
When a node reboots, it sends out a Node Initialized message. JMRI and its underlying OpenLCB_Java library see that and reset some caches. But it doesn't reset cached CDI and configuration data values. (This CDI cache is why the window opens so quickly when you open it for a 2nd time) I think this is because it takes a while to read those back in again.
Not sure of the best approach here. Thoughts appreciated.
• We could force the user to reload by e.g. closing the CDI/CD window and clearing the cache. That'll be a delay, which is unfortunate if nothing has changed. JMRI can't know whether something has changed. Some of the RR-Cirkits nodes use a reboot to put their new configuration into effect, so you end up reseting them a couple times when your developing/debugging a new configuration.
• We could give the CDI a "reload CDI" button, similar to the existing button that reloads the CD contents. But how would people know when to press it?
• Or something else I haven't thought of?
— Reply to this email directly, view it on GitHub https://github.com/JMRI/JMRI/issues/12949#issuecomment-1986556783, or unsubscribe https://github.com/notifications/unsubscribe-auth/AED27YCCUNMLKACIHVDTZMLYXJBVPAVCNFSM6AAAAABEMPCFKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGU2TMNZYGM. You are receiving this because you are subscribed to this thread.Message ID: @.***>
I thought the issue was the CDI display does show things like the firmware values changing. But tools like the firmware updater doesn't update its display when the node list (with firmware versions does update. I've watched the CDI window while updating firmware. First I see the node change to bootloader and version, then when the firmware finished loading and the node rebooted, the list showed the new version.
I thought the issue was the CDI display does show things like the firmware values changing. But tools like the firmware updater doesn't update its display when the node list (with firmware versions does update. I've watched the CDI window while updating firmware. First I see the node change to bootloader and version, then when the firmware finished loading and the node rebooted, the list showed the new version.
Could you double check this? I don’t think the CDI automatically reloads after a reboot. If it’s doing it, you’ll see the associated long delay.
Test conditions: JMRI 5.7.4plus RR-CirKits Tower+Que node LCC Node Tree displayed LCC Firmware updater used
The tree displayed the version of the node firmware before update. Once I clicked the Load in the firmware updater, the node tree display changed to show the bootloader firmware as the details of the node. When the load finished the node rebooted and the node tree updated to show the new firmware.
Initially the line in the firmware update tool showed the old firmware version. But after taking focus away from the firmware updater (to start writing this message) when I then looked at the firmware updater had refreshed to match the node tree display. I think this is a case of the update of display in the firmware tool didn't do a repaint. But taking focus away and then back, the window updated to match the node tree.
One added point. Updating the firmware does not invalidate the cached CDI for the node. In this case the update of firmware has a change in the CDI. Opening the CDI for the node still showed the old values and old format for the node. Clicking the refresh button in the CDI did not get the new CDI changes but showed the old with the old data.
Maybe having the system detect the change in firmware to invalidate the cache or add an option to the More... button to do a reload of the cache would work. Only way to see the updated CDI is exit and restart JMRI. A user has no idea the CDI is not right for the node unless they knew the CDI should show something different.
Ken,
I will repeat myself again. As I said in my first post, The LCC Tree Window behaves as you describe. That is not at issue.
If the configure window for a node is open, that DOES NOT update.
Andrew
------ Original Message ------ From "Ken Cameron" @.> To "JMRI/JMRI" @.> Cc "Andrew Crosland" @.>; "Author" @.> Date 09/03/2024 02:57:18 Subject Re: [JMRI/JMRI] LCC Config Tool Does Not Show New Firmware Version After Bootloading (Issue #12949)
I thought the issue was the CDI display does show things like the firmware values changing. But tools like the firmware updater doesn't update its display when the node list (with firmware versions does update. I've watched the CDI window while updating firmware. First I see the node change to bootloader and version, then when the firmware finished loading and the node rebooted, the list showed the new version.
— Reply to this email directly, view it on GitHub https://github.com/JMRI/JMRI/issues/12949#issuecomment-1986705390, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJWBB2XATXLWRAHHFFNZGTYXJ3A5AVCNFSM6AAAAABEMPCFKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWG4YDKMZZGA. You are receiving this because you authored the thread.Message ID: @.***>
Ken,
If you know which fields have changed, you can refresh individual fields. This is required with the Tower LCC+Q to see the results of the compile triggered by the reboot.
Dave Sand
----- Original message ----- From: Ken Cameron @.> To: JMRI/JMRI @.> Cc: Dave Sand @.>, Comment @.> Subject: Re: [JMRI/JMRI] LCC Config Tool Does Not Show New Firmware Version After Bootloading (Issue #12949) Date: Saturday, March 09, 2024 7:19 AM
One added point. Updating the firmware does not invalidate the cached CDI for the node. In this case the update of firmware has a change in the CDI. Opening the CDI for the node still showed the old values and old format for the node. Clicking the refresh button in the CDI did not get the new CDI changes but showed the old with the old data.
Maybe having the system detect the change in firmware to invalidate the cache or add an option to the More... button to do a reload of the cache would work. Only way to see the updated CDI is exit and restart JMRI. A user has no idea the CDI is not right for the node unless they knew the CDI should show something different.
— Reply to this email directly, view it on GitHub https://github.com/JMRI/JMRI/issues/12949#issuecomment-1986855490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AED27YA6H5366ONRO5UXTMDYXMD7NAVCNFSM6AAAAABEMPCFKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWHA2TKNBZGA. You are receiving this because you commented.Message ID: @.***>
Ken, If you know which fields have changed, you can refresh individual fields. This is required with the Tower LCC+Q to see the results of the compile triggered by the reboot.
The fields in the Identification segment do not have refresh buttons. Refresh all does not re-read these fileds.
The problem is that the node reboot is deliberately not clearing the cached CDI.
The question is what to do about it. Most times, a reboot does not change the CDI, so re-reading it is a waste of time. Not clearing the cache then is a mostly-correct optimization of the user experience. But it's only mostly-correct. Sometimes it's wrong.
Would it be closer to right if the firmware update tool closed the CDI window for the node (if open) and forced a reload of the CDI from that node the next time the window is opened?
That would cover the case of "firmware update changed CDI". Are there any other cases where the CDI itself, not the configuration contents of the node, changes?
Andrew,
Are you saying that by having a CDI open for a node while doing the firmware update, the node list display does not update for the firmware version changing? I read your original as the issue was the firmware updater didn't show a change in its node list for the firmware having updated. I think Bob was getting another interpretation of something else happening. I'm just trying to clarify what is the specific issue as I don't think everyone has the same picture yet.
Dave S,
My observation was the CDI itself didn't change. Like after viewing the +Que node with a 1.04 version, with the four lines for each conditional, I could not see the single multiline field (version 1.06) until I exited JMRI and restarted. Regardless of the firmware updating, and that included the CDI itself had changed, JMRI would not show that new CDI presentation until JMRI exited and restarted.
Ken,
The Tower LCC-Q upgrade from 1.04 to 1.05 (1.06 is current) does require reloading the CDI to see the change from four lines to the multiline format.
I was referring to "reboot to compile" and the three syntax status fields. After the reboot, you have to refresh the first field to see if the compile failed. If so, then also refresh the 2nd and 3rd fields to see if there are additional errors.
Dave Sand
----- Original message ----- From: Ken Cameron @.> To: JMRI/JMRI @.> Cc: Dave Sand @.>, Comment @.> Subject: Re: [JMRI/JMRI] LCC Config Tool Does Not Show New Firmware Version After Bootloading (Issue #12949) Date: Saturday, March 09, 2024 5:57 PM
Dave S,
My observation was the CDI itself didn't change. Like after viewing the +Que node with a 1.04 version, with the four lines for each conditional, I could not see the single multiline field until I exited JMRI and restarted. Regardless of the firmware updating, and that included the CDI itself had changed, JMRI would not show that new CDI presentation until JMRI exited and restarted.
— Reply to this email directly, view it on GitHub https://github.com/JMRI/JMRI/issues/12949#issuecomment-1987015283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AED27YBTCAZD77NMW2VC4U3YXOOV5AVCNFSM6AAAAABEMPCFKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGAYTKMRYGM. You are receiving this because you commented.Message ID: @.***>
I would agree that a node rebooting has nothing to do with cached CDI and likely nothing to do with cached data. One instance where a reboot of a node would change data is the status messages in the +Que node about if the conditionals compiled or not.
I would say that loading firmware to a node should consider both cached items as suspect and drop them from the cache. Unless the firmware update contained flags about if either part should be kept or purged, doing the firmware update should purge both.
A firmware update that redefines some part of the CDI, accessing the node via the older CDI likely would be wrong for some of the data.
Andrew, Are you saying that by having a CDI open for a node while doing the firmware update, the node list display does not update for the firmware version changing? I read your original as the issue was the firmware updater didn't show a change in its node list for the firmware having updated.
I don't know how to make it any clearer. I think Bob has the correct interpretation.
The LCC Tree Window (form the LCC menu "configure nodes) updates.
The Configure window, i.e. a window to a specific node opened from the tree display by clicking "Open configuration dialog" against a node does not update.
That would cover the case of "firmware update changed CDI". Are there any other cases where the CDI itself, not the configuration contents of the node, changes?
It would be useful during node development to be able to see changes to the CDI itself, e.g., when using an attached programmer, not the bootloader, without having to restart JMRI. That's only applicable to developers, not users.
Tools that show firmware values. I know of the tree display and the CDI for the node. By extension the STL editor would also come into this. I don't know what else currently exists that deal with display of the firmware values.
Firmware changes.
- no CDI change, no data change. Just fixing software bugs or features.
- no CDI change, use of data changes. Like range of valid values in a field grows or shrinks.
- CDI change, no data change. Cosmetic like name changes or display changes but content stays.
- CDI change, data changes. Redefining existing fields.
Any of these should have any display of the firmware version gets updated. But depending on the above matrix, neither, only one, or both the prior CDI or data becomes invalid.
While the impact of these is greater on those doing development, it does impact users. Somebody here might know what would happen if you used an older CDI to edit values in a node? But I think not insuring the different parts keep in sync will troublesome users.
Now the case of where some data within a CDI should never be cached, I can think of things like voltage/current reports or the +Que compile results would be examples. If it is going to display those, it should be the current values. I have no idea if something like this exists in the CDI. Same about if it could become something in the CDI.
I'm hoping I've covered the use cases we're seeing.
Does anyone have any thought about fixing this?
Just to be clear, as there seems to be a lot of confusion. Here's the tree display of a node after updating with the bootloader
And here is the config display for the same node. The Software version does not update.
This is confusing to users.
The question is which is better:
A) require a full reload of the status of the node after an Initialization Complete message indicates it has rebooted B) Cache the content of the PIP, SNIP and/or CDI information across an Initiaiization Complete
I think what JMRI does is to re-read the PIP and SNIP information without forcing a e-read of the CDI. That changes the information in the configuration tree display, but not in the CDI display.
Reading the CDI takes a bunch of time. Until the Tower-Q came along and the STL editor was created, perhaps that wasn't a big deal. Reboots were rare. The Tower-Q does a reboot every time you want to check the STL you're editing. It would be painful if that required a complete re-read of the CDI. Still, we could do that.
Better might be to have the Firmware Update process invalidate the CDI cache, forcing a re-read of it afterwards. But those two things are far apart in the code, and it's not apparent to me how to do that. Perhaps somebody else knows of a good way to do this?
Would it be possible to have the "Refresh All" button re-populate the Identification segment with the updated version? That would at least allow a manual workaround.
If a node had been given new firmware, JMRI would need to see the (potentially) new CDI. Does that happen? I'm trying to remember if I've seen that in the past or not. Just a node reboot, no need to get it again. But a firmware change should as the CDI frequently is part of the change of firmware. I would think, if JMRI knows of a firmware change, it should invalidate anything cached about the node. Data values, CDI, etc... all might be different.
Would it be possible to have the "Refresh All" button re-populate the Identification segment with the updated version? That would at least allow a manual workaround.
This comment confuses me. Could you provide more detail, please?
The "Refresh All" button is on the "OpenLCB Network Tree" window. AFAIK, that button properly refreshes the info in that window via SNIP and PIP requests.
Are you referring to the "identification segment" in a "Configure ..." window? That's displaying the most recent CDI information.
The "OpenLCB Network Tree" window has a "Refresh" button, not "Refresh All" (actually I have an LCC connection so its "LCC Network Tree":
The "Refresh All" button is at the bottom of the "Configure..." window:
The "Refresh All" button does not update the Identification segment.
This issue is stale because it has been open for 45 days with no activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}