Cannot get reply to memoryService.requestSpaceLength call

[jeff-tcs]

I am currently retrieving a far node's memory image data via a call to MemoryReadMemo(NodeID(nodeID.id), 64, 0xFF, 0, memoryReadFail, memoryReadSuccess) I am getting replies with the callback "memoryReadSuccess". I know that all frames have been received by checking for a < 64 bytes message content length and a 0 byte terminator. I have tried calling memoryService.requestSpaceLength(0xFF, NodeID(nodeID.id), callback=memorySpaceCallback) and when I have a debug breakpoint in the memorySpaceCallback method the breakpoint is never reached. For example if I send a request to the TCS CS and monitor the lights I noticed some activity with the data light for a short while but it seems to never return a reply back to me. Can this memory service call be "ignored" by a far node? It seems like that is the case. I would like to use the requestSpaceLength return value as part of my logic for a Progress GUI widget in the UI. Please advise. Thanks.

[jeff-tcs]

Title should have been "Cannot get reply to memoryService.requestSpaceLength call"

[bobjacobsen]

The far node shouldn't be ignoring that request. Can you please check on the CAN bus to make sure the request is going out and the reply is coming back? I'm away from hardware for a bit, but should be able to test this tomorrow night.

[jeff-tcs]

From the way the data light is flickering I believe the request is getting to the Command Station...not exactly scientific I know...but I could probably put some breakpoints in the memoryservice code for sending the request and looking for the returning reply in the code. If you think that might help diagnose the issue

On Tue, May 28, 2024 at 3:16 PM Bob Jacobsen @.***> wrote:

The far node shouldn't be ignoring that request. Can you please check on the CAN bus to make sure the request is going out and the reply is coming back? I'm away from hardware for a bit, but should be able to test this tomorrow night.

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2135943785, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFEGFEPTKR7XYPTAQELZETJ2FAVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVHE2DGNZYGU . You are receiving this because you authored the thread.Message ID: @.***>

[bobjacobsen]

Could you post the snippet of code where you setup and request the memory address space info? Thanks. I can try to run that here and do some debugging.

[bobjacobsen]

@jeff-tcs I just pushed example_memory_length_query.py for an example of how to do a memory query.

That same PR fixes a bug in processing the memory length query.

Could you pull the main branch to pick those up? Thanks, and sorry for the trouble.

[jeff-tcs]

Bob thank you for reaching out. I'll try the example and let you know the results. Also I will try doing the length request with my dev code and let you know the results. What was the bug / problem that you found?

On Wed, May 29, 2024 at 10:59 AM Bob Jacobsen @.***> wrote:

@jeff-tcs https://github.com/jeff-tcs I just pushed example_memory_length_query.py for an example of how to do a memory query.

That same PR fixes a bug in processing the memory length query.

Could you pull the main branch to pick those up? Thanks, and sorry for the trouble.

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2137630607, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFASWBB5DFEDIDKNR4LZEXUO5AVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZXGYZTANRQG4 . You are receiving this because you were mentioned.Message ID: @.***>

[jeff-tcs]

Bob I pulled the python-openlcb branch but did not receive the example_memory_length_query.py code file.

On Wed, May 29, 2024 at 11:18 AM Jeff Snyder @.***> wrote:

Bob thank you for reaching out. I'll try the example and let you know the results. Also I will try doing the length request with my dev code and let you know the results. What was the bug / problem that you found?

On Wed, May 29, 2024 at 10:59 AM Bob Jacobsen @.***> wrote:

@jeff-tcs https://github.com/jeff-tcs I just pushed example_memory_length_query.py for an example of how to do a memory query.

That same PR fixes a bug in processing the memory length query.

Could you pull the main branch to pick those up? Thanks, and sorry for the trouble.

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2137630607, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFASWBB5DFEDIDKNR4LZEXUO5AVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZXGYZTANRQG4 . You are receiving this because you were mentioned.Message ID: @.***>

[bobjacobsen]

That's odd. Perhaps something went wrong with the pull from main?

The two modified files are: https://github.com/bobjacobsen/python-openlcb/blob/main/example_memory_length_query.py https://github.com/bobjacobsen/python-openlcb/blob/main/openlcb/memoryservice.py

There were two changes to the memoryservice.py file:

• fix format of query message (which was throwing an exception during creation)
• fix calculation of address value from the reply message

[jeff-tcs]

I got the memoryservice.py file update but not the example_memory_length_query.py https://github.com/bobjacobsen/python-openlcb/blob/main/example_memory_length_query.py file

On Wed, May 29, 2024 at 11:49 AM Bob Jacobsen @.***> wrote:

That's odd. Perhaps something went wrong with the pull from main?

The two modified files are:

https://github.com/bobjacobsen/python-openlcb/blob/main/example_memory_length_query.py

https://github.com/bobjacobsen/python-openlcb/blob/main/openlcb/memoryservice.py

There were two changes to the memoryservice.py file:

• fix format of query message (which was throwing an exception during creation)
• fix calculation of address value from the reply message

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2137739773, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFENFJYMFZQLXSO6X3TZEX2JVAVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZXG4ZTSNZXGM . You are receiving this because you were mentioned.Message ID: @.***>

[jeff-tcs]

Bob, I got my memoryService.requestSpaceLength(0xFF, NodeID(nodeID.id), callback=memorySpaceCallback) code running but I had to also put a time.sleep(1) in before the request was initiated. Then it started to run and my follow on code doing the memMemo = MemoryReadMemo(NodeID(nodeID.id), 64, 0xFF, 0, memoryReadFail, memoryReadSuccess) kicked in as normal. But the memorySpaceCallback(length) oode is receiving a memory space length of 0 bytes.

I also copied the example_memory_length_query.py code down from Github (had to cut and paste it into a visual studio file). It also returns a memory space length of 0 bytes. So my callback is now returning but with a 0 byte length. And I see that the request is getting to the TCS Command Station with a return.

On Wed, May 29, 2024 at 11:53 AM Jeff Snyder @.***> wrote:

I got the memoryservice.py file update but not the example_memory_length_query.py https://github.com/bobjacobsen/python-openlcb/blob/main/example_memory_length_query.py file

On Wed, May 29, 2024 at 11:49 AM Bob Jacobsen @.***> wrote:

That's odd. Perhaps something went wrong with the pull from main?

The two modified files are:

https://github.com/bobjacobsen/python-openlcb/blob/main/example_memory_length_query.py

https://github.com/bobjacobsen/python-openlcb/blob/main/openlcb/memoryservice.py

There were two changes to the memoryservice.py file:

• fix format of query message (which was throwing an exception during creation)
• fix calculation of address value from the reply message

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2137739773, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFENFJYMFZQLXSO6X3TZEX2JVAVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZXG4ZTSNZXGM . You are receiving this because you were mentioned.Message ID: @.***>

[bobjacobsen]

That return of 0 length is one of the things I fixed in the memoryservice.py file. Could you try copying that one down from GitHub to see if that fixes it for you? Sounds like something went wrong in your git pull and you didn't get either update.

https://github.com/bobjacobsen/python-openlcb/blob/main/openlcb/memoryservice.py

[jeff-tcs]

Ok will do I have to get with Jake tomorrow and figure it out why I am having trouble pulling stuff from openlcb. Thanks

On Wed, May 29, 2024 at 5:02 PM Bob Jacobsen @.***> wrote:

That return of 0 length is one of the things I fixed in the memoryservice.py file. Could you try copying that one down from GitHub to see if that fixes it for you? Sounds like something went wrong in your git pull and you didn't get either update.

https://github.com/bobjacobsen/python-openlcb/blob/main/openlcb/memoryservice.py

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2138259332, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFAMA6WSZGFOARKUU3LZEY67XAVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZYGI2TSMZTGI . You are receiving this because you were mentioned.Message ID: @.***>

[jeff-tcs]

Ok with the new copy of memoryservice.py I am getting the node memory image byte length. Thanks. New subject. Do you have example code for me that would give an idea of how I should basically take a CDI change update and write it back to a location in the far node memory image?

[bobjacobsen]

Do you have example code for me that would give an idea of how I should basically take a CDI change update and write it back to a location in the far node memory image?

The tricky part of that is figuring out the address of each variable described by the CDI. You have to parse the CDI XML, keeping track of the address as you go through each element. I don't have that code in Python. The Java version is here:

https://github.com/openlcb/OpenLCB_Java/tree/master/src/org/openlcb/cdi/jdom

This Python implementation was made from the Swift implementation, which has a more Python-like structure:

https://github.com/bobjacobsen/OpenlcbLibrary/tree/main/Sources/OpenlcbLibrary/XML

Are you trying to write a general CDI tool? Or something more specific?

[jeff-tcs]

I am writing code for a new application that initially will provide a general CDI tool capability

cross platform which will allow a user to query for a far node ID list in an LCC Network. Then select

a specific far node and retrieve it’s memory configuration image. First level detail will be the display of

SNIP (mfg’s and user info) and Protocol Support information. Second level detail will again include mgf’s

info and user related elements along with the entire display of the remaining CDI elements that can be

viewed / changed by the user. The user can then change the content of a specific CD element(s)

and subsequently send the changed element(s) content back to the far node to update its memory image.

Code is written in python and I am using KivyMD widgets for the GUI user interface allowing for “touch”

and / or “mouse” activation / navigation on the screen over multiple hardware platforms. I am using the

built-in xml.sax parser with either a regular handler or scream handler (haven’t decided yet).

I have been to-date looking at how you do the parsing in CdiParserDelegate.swift within OpenlcbLibraryXML directory as a guide to writing the parsing code.

It looks like you are grabbing an address from the 'origin' attribute of the start element to save for future reference. Is that the only place where an address value is

specified? So far I don't see any address value referenced otherwise. Also in my parser handler do I need to have the same number of 'cases' to break down on

for processing the XML content?

I will start looking at your links for further understanding on creating the parser code.

Can you suggest specific OlcbTools/shared swift View code examples that might help me understand how best to

take element(s) info from the GUI and prepare it for sending the element update thru a memory write request call.

I appreciate you guidance in all the above.

On Thu, May 30, 2024 at 7:34 AM Bob Jacobsen @.***> wrote:

Do you have example code for me that would give an idea of how I should basically take a CDI change update and write it back to a location in the far node memory image?

The tricky part of that is figuring out the address of each variable described by the CDI. You have to parse the CDI XML, keeping track of the address as you go through each element. I don't have that code in Python. The Java version is here:

https://github.com/openlcb/OpenLCB_Java/tree/master/src/org/openlcb/cdi/jdom

This Python implementation was made from the Swift implementation, which has a more Python-like structure:

https://github.com/bobjacobsen/OpenlcbLibrary/tree/main/Sources/OpenlcbLibrary/XML

Are you trying to write a general CDI tool? Or something more specific?

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2139359605, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFBKQQQU3TTKYEYF4NLZE4FELAVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZZGM2TSNRQGU . You are receiving this because you were mentioned.Message ID: @.***>

[bobjacobsen]

Thanks for the info. To answer some specific questions:

It looks like you are grabbing an address from the 'origin' attribute of the start element to save for future reference. Is that the only place where an address value is specified? So far I don't see any address value referenced otherwise.

Each of the integer, float, event and string elements increments the address, and the enclosing group element can cause that to happen multiple times. So you have to keep track of that as you parse the XML.

Also in my parser handler do I need to have the same number of 'cases' to break down on for processing the XML content?

I don't know. I think you have to parse everything to follow the addresses, see above. But there are probably multiple ways to set up that code.

Can you suggest specific OlcbTools/shared swift View code examples that might help me understand how best to take element(s) info from the GUI and prepare it for sending the element update thru a memory write request call.

For your choice of interface widgets, I think the closest thing is probably

https://github.com/openlcb/OpenLCB_Java/blob/master/src/org/openlcb/cdi/swing/CdiPanel.java

That takes the CDI representation and visits through it to create the corresponding GUI elements.

[jeff-tcs]

This is very helpful and enlightening. For the moment I think I have everything I need to move forward. Thanks.

On Thu, May 30, 2024 at 12:02 PM Bob Jacobsen @.***> wrote:

Thanks for the info. To answer some specific questions:

It looks like you are grabbing an address from the 'origin' attribute of the start element to save for future reference. Is that the only place where an address value is specified? So far I don't see any address value referenced otherwise.

Each of the integer, float, event and string elements increments the address, and the enclosing group element can cause that to happen multiple times. So you have to keep track of that as you parse the XML.

Also in my parser handler do I need to have the same number of 'cases' to break down on for processing the XML content?

I don't know. I think you have to parse everything to follow the addresses, see above. But there are probably multiple ways to set up that code.

Can you suggest specific OlcbTools/shared swift View code examples that might help me understand how best to take element(s) info from the GUI and prepare it for sending the element update thru a memory write request call.

For your choice of interface widgets, I think the closest thing is probably

https://github.com/openlcb/OpenLCB_Java/blob/master/src/org/openlcb/cdi/swing/CdiPanel.java

That takes the CDI representation and visits through it to create the corresponding GUI elements.

— Reply to this email directly, view it on GitHub https://github.com/bobjacobsen/python-openlcb/issues/44#issuecomment-2140071011, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGIWXFHYP37PUEAJHPUGRU3ZE5ESNAVCNFSM6AAAAABINIESDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQGA3TCMBRGE . You are receiving this because you were mentioned.Message ID: @.***>