Firmware for 7i80 +SSI +7i48 +7i84

My system seems to parse the ini and hal files a bit differently...
In HAL i need to remove the parenthesis to ini parameters I.e.
loadrt [HOSTMOT2]DRIVER config=[HOSTMOT2]CONFIG works better than above examples, but i get some error about { character from the parser...
Doesn't matter: after lots of testing I found the working string for me was:
loadrt hm2_eth board_ip="192.168.1.121" board_mac="00:60:1B:11:80:11" "config=num_encoders=6 num_pwmgens=6 ssi_chan_0=steps%12eturns%12e"
Quite strange placements of the " characters... after =sign at the first parameters but surronding config.

I got SSI working. But i couldn't read out the correct values. From very, very slow rotation I get position values in sequences looking like this:
-2966711, -2966706, -2966705, -2966708, -2966707, -2966718, -2966717, -2966720, -2966719
Not exactly a straight counting. I have tested lots of different format strings but couldn't find a correct one. But I will call encoder manufacturer tomorrow to see if they can give me the SSI datastring formatting (tr-electronics)

Anyhow. I installed master now to get the latest development of hm2-eth
But now I don't get any SSI pins at all. The SSI encoder is found in the list of pins that shows when driver is loaded, but no SSI in hal-configuration.

P.S After installing master i needed to edit the above loading string to:
loadrt hm2_eth "board_ip=192.168.1.121 board_mac=00:60:1B:11:80:11 config=num_encoders=6 num_pwmgens=6 ssi_chan_0=steps%12eturns%12e" Now only qoutes around the whole string.

Not sure about the parsing changes (what I posted was a working configuration)

I will try again with master
(try doing a rebuild of master because you are not up-to date, the latest has no mac address)

ps for SSI you may have the clock and or data inverted (or you may have gray code)

Aha
When I removed the board_mac parameter I could again split up the string with more quotes and then the config string was apparently parsed better, so now the ssi is back working.
Works now:
loadrt hm2_eth board_ip="192.168.1.121" "config=num_encoders=6 num_pwmgens=6 ssi_chan_0=steps%12eturns%12e"

I'm happy with writing all in the hal file, but in case you like to troubleshoot the problem with parsing with parameters from ini I made some tests:.
With this in ini:
[HOSTMOT2]
DRIVER=hm2_eth board_ip="192.168.1.121"
CONFIG="num_encoders=6 num_pwmgens=6 ssi_chan_0=position%24ge"

This in hal:
loadrt [HOSTMOT2](DRIVER) [HOSTMOT2](CONFIG)

Give me error:
Starting LinuxCNC...
twopass: invoked with <> options
twopass: Error in file Leadwell_hm2.hal:
can't read "::HOSTMOT2((DRIVER)": no such element in array




This:
loadrt [HOSTMOT2]DRIVER config=[HOSTMOT2]CONFIG

Give me error:
...
...
hm2: loading Mesa HostMot2 driver version 0.15
{hm2_eth board_ip="192.168.1.121"}: dlopen: /home/mattias/linuxcnc-dev/rtlib/{hm2_eth board_ip="192.168.1.121"}.so: cannot open shared object file: No such file or directory
/home/mattias/linuxcnc-dev/bin/rtapi_app exited without becoming ready
insmod failed, returned -1
while executing
"hal loadrt {{hm2_eth board_ip="192.168.1.121"}} {config={"num_encoders=6 num_pwmgens=6 ssi_chan_0=position%24ge"}}"
...
...




With this I got a bit different error:
ini:
[HOSTMOT2]
DRIVER=hm2_eth
ADDR="192.168.1.121"
CONFIG="num_encoders=6 num_pwmgens=6 ssi_chan_0=position%24ge"

hal:
loadrt [HOSTMOT2]DRIVER board_ip=[HOSTMOT2]ADDR config=[HOSTMOT2]CONFIG

error:
...
...
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: ERROR: can't connect: Permission denied
RTNET layer not ready
hm2_eth: ERROR: can't close socket: Transport endpoint is not connected
hm2_eth: rtapi_app_main: -13
/home/mattias/linuxcnc-dev/bin/rtapi_app exited without becoming ready
insmod failed, returned -1
while executing
"hal loadrt hm2_eth board_ip={\"192.168.1.121\"} {config={"num_encoders=6 num_pwmgens=6 ssi_chan_0=position%24ge"}}"
("eval" body line 1)
...
...

I'm pretty tired, late at night here, so there may be silly typos in above testing......

I would just use the exact syntax in my example files (since they do work)

These are taken verbatim from the hm2-servo.hal and 5ixx.ini sample config files
with the added Ethernet options to the driver

of course the latest hm2_eth drops the mac address so you have to remove that

I now copy and pasted your exact examples above. Removed the board_mac parameter and adjusted ip-address.
I get:
can't read "::HOSTMOT2((DRIVER)": no such element in array

Maybe the main difference is that I am using Ubuntu with 3.10.4-rt1mah kernel. I guess most testing has been done on Debian? Could this make any difference? Are the same shell used in those?


I also have a question regarding the documentation of 7i44. The RJ45 pinout on page 5 (footer page number, page 8 of pdf) says:
1 tx- ; 2 tx+ ; 3 rx- ; 6 rx+
When I connected my SSI encoder that way I got the data stream bits inverted, that caused the strange position count sequence noted above.

When I instead connected the encoder to 7i44 as 1 tx+ ; 2 tx- ; 3 rx+ ; 6 rx- the data is now received correctly.
1 tx+ ; 2 tx- ; 3 rx+ ; 6 rx- is the most common pinout for RJ45 when I made a googling. Should it maybe be like that in the 7i44 documentation?

Is it possible you edited the ini file/hal file with a windows editor?

I can see no other reason for the parsing errors

I would try my file set as is (you may have to change the IP address, make sure
you do it with a editor like gedit)

The OS should make no difference (I am using various Ubuntu versions and the parsing works on all)

The 7I44 pinout polarities are designed to match RS-422 serial polarities where the + signal is equivalent to the single ended RS-423/RS-232 signal polarity

I have only used gedit to edit my ini and HAL. I started by copying and making changes to hm2_servo.hal and i think it was 5i20.ini.
I had to change all places with hm2_[HOSTMOT2](BOARD) to hm2_7i80.

Why is the hostmot2 parameters written with () but with all other parameters, and also according to HAL documentation, no () characers are used?
Examples from HM2_servo.hal:
If you don't think it's a good thing to straight this out to get a stable release in future we can leave this question since me personally think its easier and cleaner to have it all written directly in the HAL file without passing from ini.


For the pinout polarities I don't understand your parallells to RS-232. I just wanted to check that it was no typo in the documentation.
My encoders are specified to have a electrical interface according to RS-422 with SSI protocol with 24bit gray code.
When I connected like this:

Encoder	7i44
SSI_Clk-_In	Pin 1 Tx-
SSI_Clk+_In	Pin 2 Tx+
SSI_data-_Out	Pin 3 Rx-
SSI_data+_Out	Pin 6 Rx+
Not connected	Pin 4, 5, 7, 8

I got all databits inversed.

When I changed my connection to:

Encoder	7i44
SSI_Clk-_In	Pin 2 Tx+
SSI_Clk+_In	Pin 1 Tx-
SSI_data-_Out	Pin 6 Rx+
SSI_data+_Out	Pin 3 Rx-
Not connected	Pin 4, 5, 7, 8

I got nice looking position data. Using this format string: ssi_chan_0=pos%24ge

To figure out that the data was inverted I looked at the data with this string: ssi_chan_0=steps%12eturns%12e I.e. without gray-switch
The turn numbers were easier to look at since i didn't need to turn the encoder with such high precision to get all changes in the sequence.
I converted the decimal turn.count to binary values and looked at the sequence of the last 4 bits and discovered that it was a kind of gray code (i.e. one bit changing for each step) but not the usual gray code sequence (found when googling gray code). If I inverted all bits in my data I recognized it was the normal gray code sequence. Hence I changed polarity of my RS422 connection.
I don't know if it was correct to change Tx polarity but it seems to work now...

I'm not sure what parsing problem you have, can you try the files I sent?

Note the hm2-servo.hal file has been unchanged for at least 7 years and works for me with
linuxcnc 2.5, 2.5.4, 2.6pre4, and master (2.7) under various linux OSes and RTOS's

Our RS-422 polarities match the RS-449 specification for RS-422 and RS423 interoperability
(so RS-232 also) Since the 7I44 is most often used for RS-422 serial communications, this is the most appropriate signal naming.