Getting current User Info Settings back from a Node when I am doing memory read transactions with CDI configuration tool.

[jeff-tcs]

Hi Bob I am using the memoryservice calls to read in far node CDI memory in my configuration tool for TCS. I am pulling the tag/value information including values where appropriate. However when I am using my XML parser with a content handler in python, in particular, when I pull in and parse the segment with "User Info Settings" I get in the name, description and string tags. The string tag/values have the "User Name" and "User Description" each but I am not receiving any actual "string value" for each.
Do I need to display that at the user interface from the Node's SNIP information? And then with a textfield widget change that information back at the Node with a write operatiion to the associated address? Because I am not receiving any actual string data from the Node. So do I need to initially just display the Node's SNIP user info in my CDI screen and then change it by writing back those changes made by the user in the associated text input fields? Please advise. Thanks.
Jeff

[bobjacobsen]

Not entire sure what's you're trying to do here. The CDI (memory space 0xFF) doesn't contain the user name and description. That's in the configuration memory itself: memory space 0xFD. The CDI just describes where to find the user name and description.

[jeff-tcs]

Bob thanks for replying back. I realize that the CDI xml data sent by the far node would not actually have the configuration variable (CV) information contained in the XML data itself. But I was hoping (against hope) that the far node would normally be smart enough to send along the initial actual cv values associated with each segment's XML CDI data. Therefore making it unnecessary to initiate a separate read operation. So given the need for me to do a read request for each CV referenced in the XML, is the address for a CV memory location calculated by taking the origin and space values of the associated segment and then adding one or more offset(s) for the selected CV within the segment to get the actual CV address for the read request? I know we discussed this before but just wanted to confirm again. Thanks, Jeff

…

On Thu, Jun 27, 2024 at 7:04 PM Bob Jacobsen ***@***.***> wrote: Not entire sure what's you're trying to do here. The CDI (memory space 0xFF) doesn't contain the user name and description. That's in the configuration memory itself: memory space 0xFD. The CDI just *describes* where to find the user name and description. — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGIWXFF2EUSTYOOMIJJKIXLZJSLAVAVCNFSM6AAAAABKAQUXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJVHAYDIMJTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bobjacobsen]

So given the need for me to do a read request for each CV referenced in the XML, is the address for a CV memory location calculated by taking the origin and space values of the associated segment and then adding one or more offset(s) for the selected CV within the segment to get the actual CV address for the read request?

Right! That's the general solution.

You can check your calculation by running JMRI or LccTools and looking at what address its using when accessing a particular value.

For the specific case of the user information, you can check the PIP values to see if ACDI is indicated. If it is, the user name and description are at fixed constant addresses that you can use directly. See section 5.1.2 of the CDI standard doc. Most nodes do this now.

[jeff-tcs]

Bob thank you for the info and the tips. I will check out my address calculations with JMRI and/or your LccTools.

…

On Fri, Jun 28, 2024 at 1:27 PM Bob Jacobsen ***@***.***> wrote: So given the need for me to do a read request for each CV referenced in the XML, is the address for a CV memory location calculated by taking the origin and space values of the associated segment and then adding one or more offset(s) for the selected CV within the segment to get the actual CV address for the read request? Right! That's the general solution. You can check your calculation by running JMRI or LccTools and looking at what address its using when accessing a particular value. For the specific case of the user information, you can check the PIP values to see if ACDI is indicated. If it is, the user name and description are at fixed constant addresses that you can use directly. See section 5.1.2 of the CDI standard doc. Most nodes do this now. — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGIWXFCNCZ3A5SEMKA2I5HTZJWMGZAVCNFSM6AAAAABKAQUXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGM3DMNZTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeff-tcs]

Bob, I have a follow on question. I was able to read the CV values for User Name and Description CVs from the command station. I referred to your openlcb "example_memory_transfer.py" in writing my new code for extraction of CV values. This example of yours shows a memoryRead() example only. Do you also have an example_memory_transfer type file that also includes a memory write operation to a CV in a far node? I would like to have such an example as a reference when I create the new CV write memory code. Appreciate your help in this matter. Thanks Jeff

…

On Fri, Jun 28, 2024 at 2:50 PM Jeff Snyder ***@***.***> wrote: Bob thank you for the info and the tips. I will check out my address calculations with JMRI and/or your LccTools. On Fri, Jun 28, 2024 at 1:27 PM Bob Jacobsen ***@***.***> wrote: > So given the need for me to do a read request for each CV referenced in > the XML, is the address for a CV memory location calculated by taking the > origin and space values of the associated segment and then adding one or > more offset(s) for the selected CV within the segment to get the actual CV > address for the read request? > > Right! That's the general solution. > > You can check your calculation by running JMRI or LccTools and looking at > what address its using when accessing a particular value. > > For the specific case of the user information, you can check the PIP > values to see if ACDI is indicated. If it is, the user name and description > are at fixed constant addresses that you can use directly. See section > 5.1.2 of the CDI standard doc. Most nodes do this now. > > — > Reply to this email directly, view it on GitHub > <#47 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BGIWXFCNCZ3A5SEMKA2I5HTZJWMGZAVCNFSM6AAAAABKAQUXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGM3DMNZTGI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[bobjacobsen]

The write is very similar to the read. You create a write memo with the information:

memo = MemoryWriteMemo(nodeIDtoWriteTo,
                                                   goodCallback, badCallback,
                                                   size, space, address,
                                                   dataArray)

and when you're ready, you invoke that:

memoryService.requestMemoryWrite(memo)

then wait for the good or bad callback

[jeff-tcs]

Thanks, I will!

…

On Mon, Jul 1, 2024 at 2:34 PM Bob Jacobsen ***@***.***> wrote: The write is very similar to the read. You create a write memo with the information: memo = MemoryWriteMemo(nodeIDtoWriteTo, goodCallback, badCallback, size, space, address, dataArray) and when you're ready, you invoke that: memoryService.requestMemoryWrite(memo) then wait for the good or bad callback — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGIWXFCOPWMRJD3PPXVGXFLZKGOLRAVCNFSM6AAAAABKAQUXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQG43TQMBVHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeff-tcs]

Bob, Thank you for your help on me doing memo reads/writes. I am reading and writing memory locations on the tcs command station. I have two questions about the references in each segment xml item read in when pulling the XML from a far node: - The "origin" number on the segment start tag. Is it referencing an actual memory address location in the far node? - The "space" number on the segment start tag. What does it signify or reference? Is it relative to the origin address? Additional question - for the command station case I am reading in empty group tag/values between segment tag/values as noted: <group offset="48"/> <group offset="4"/> Do i need to add those offset addresses to subsequent tag origin addresses to correctly set their origin address? Thanks. Jeff

…

On Mon, Jul 1, 2024 at 2:36 PM Jeff Snyder ***@***.***> wrote: Thanks, I will! On Mon, Jul 1, 2024 at 2:34 PM Bob Jacobsen ***@***.***> wrote: > The write is very similar to the read. You create a write memo with the > information: > > memo = MemoryWriteMemo(nodeIDtoWriteTo, > goodCallback, badCallback, > size, space, address, > dataArray) > > and when you're ready, you invoke that: > > memoryService.requestMemoryWrite(memo) > > then wait for the good or bad callback > > — > Reply to this email directly, view it on GitHub > <#47 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BGIWXFCOPWMRJD3PPXVGXFLZKGOLRAVCNFSM6AAAAABKAQUXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQG43TQMBVHA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[bobjacobsen]

Glad you're making progress!

"space" refers to the various memory spaces defined by the Memory Configuration Standard. The CDI is always in the 0xFF memory space. The configuration data itself is (usually) in the 0xFD memory space. You copy that value into the "space" argument in your memory read and write requests.

"origin" is the starting memory address in the far node for that segment. All the various integer, string, etc variables then increment that by their size. "origin" is often zero, but it doesn't have to be.

I don't know for sure about the <group offset="48"/> and <group offset="4"/>. I think you need to add those offsets to the address you're accumulating as you go through the CDI. But I'm not sure. You might want to check what JMRI is doing with those.

[jeff-tcs]

Thank you for the reply. I'll check with JMRI on the group offsets.

…

On Tue, Jul 16, 2024 at 11:14 AM Bob Jacobsen ***@***.***> wrote: Glad you're making progress! "space" refers to the various memory spaces defined by the Memory Configuration Standard. The CDI is always in the 0xFF memory space. The configuration data itself is (usually) in the 0xFD memory space. You copy that value into the "space" argument in your memory read and write requests. "origin" is the starting memory address in the far node for that segment. All the various integer, string, etc variables then increment that by their size. "origin" is often zero, but it doesn't have to be. I don't know for sure about the <group offset="48"/> and <group offset="4"/>. I think you need to add those offsets to the address you're accumulating as you go through the CDI. But I'm not sure. You might want to check what JMRI is doing with those. — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGIWXFCVIJBFBD7QWSWJJYLZMU2HDAVCNFSM6AAAAABKAQUXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGE4TCMJVGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>