iPM app interactive feedback

janineA commented 4 months ago

From Josh:

I feel that the functionality difference between '$ sudo ipm_ctrl {args}' and '$ ipm_ctrl {args}' is unexpected and prone to user error. I think it would be less prone to user error if the register configuration functionality was moved to a flag option (requiring elevated privileges). Can we change that?
./ipm_ctrl -i -a 2 -c VER?
- This command should print the response data as a string. It should not report success/failed comparison to 'VER A022(L)...'.
- SERNO? and BITRESULT? should also print their responses as a string, and Hex values respectively.
Running ipm_ctrl must have a return code. Success should return 0. Execution currently always returns 1. <- Resolved with commit ab2f32a cjw
Verbose mode is great information, but is a bit messy due to the ASCII interpretation of the byte data which is often interpreted with a newline. Can this be reported more cleanly? Bytes without ASCII characters should not be printed.
Can "debug mode, -d" be changed to "hexidecimal output mode, comma-delimited, -H"?
Let's use "device" instead of "port" when specifying /dev/ttyS0. A '-D' {device} flag is consistent with minicom
Please specify more meaning to "procqueries" and "port" parameter of the -# flag fields in the help blurb.

Please add some typical examples to the ipm_ctrl help blurb. Useful examples (please double check)

$ ./ipm_ctrl -i -a 2 -D /dev/ttyS0 -c RECORD?          ### Interactive, Send a single RECORD? query to iPM address 2 on /dev/ttyS0
$ ./ipm_ctrl -i -a 1 -D /dev/ttyS0 -c MEASURE? -H   ### Interactive, Send a single MEASURE? query to iPM address 1 on /dev/ttyS0 and out hex values
$ ./ipm_ctrl -i                                                             ### Interactive, Start menu-based control of iPM
$ ./ipm_ctrl -m 1 -r 10 -n 2 -0 0,5,30101 -1 2,5,30102 -D /dev/ttyS0   ### Launch full application with bus identification at two addresses, initialization, periodic data queries and transmission to network IP port.

In playing with this app, it is apparent that outputting data in hexidecimal mode 1) more closely represents the raw data, and 2) is a shorter string than with decimal output data. Both of these characteristics are good for the .ads file. So, an option here is to transmit/store the comma-delimited hex data string and have nimbus do the scaling. I'd like to discuss this with you at the next opportunity.