Advanced Search

you can see here that even best fine tuned usb devices on RT kernel has a round trip close to 10ms
interfacinglinux.com/linux-compatible-audio-interfaces/
compared to stable 0.1-0.5ms with Ethernet or SPI

Excellent!

if you plan to use Orange PI why not just dedicate few pins and use SPI. RIO already has the driver and i believe works on other spartan 6 boards like a charm. you can use usb for firmware updates and non real time data (like pendant for example). usb has great speed but absolutely no guarantee time wise especially if your board will identify itself as vendor specific class. you can try to play with usb audio devices class, which seem to have better latency but you may still be disappointed after all that hard work you plan to do.

Well, the board has arrived and i think i know now why these are so cheap. I can see the signs of dust, discoloration and rework. Looks like these boards are taken from old equipment and refurbished. I will use it for my fpga learning experiments but would not recommend for any serious use.

I guess this closes the topic.

Thank You , I have had other things happening , ill try and work on it this weekend.

It's not speed that is the issue, it's regularity. Once you introduce a buffer you lose the ability for realtime response.
There's a reason that no USB development has been done for Linuxcnc.
Search the forum for questions related to USB and you'll get the same response over and over.
Mesa has one or two boards that have USB interfaces but none are used for Linuxcnc.

As previously stated, Ethernet, SPI or EPP are the way to go. USB maybe ok for control panels for non realtime input, but disconnection can be an issue.

I really suggest you look into it more, especially the difference between speed and regularity. You may also want to look to see if USB has any realtime drivers.

Should be something like:

sserial_port_0=000xxxxx

or

sserial_port_0=002xxxxx

Assuming you want the 7I84 to run in mode 2.

There is no sserial_port_1 in 7i77x2 configurations
(there is only sserial_port_0 with 6 channels, 3 for the first 7I77 and 3 for the second)

Yes, I overlooked the /usr/bin/pncconf in my search. The problem was that the pin number for the 7i95t first encoder port was 0 which caused "if self.d._arcvin ..." to evaluate to false. I fixed it by using "if self.d._arcvin != None ...".

Video on youtube?

Outside of my use of StepConf - any suggestion as to what I might want to look at to understand why the rapid moves of SHIFT-RT/LT/UP/DN/PG UP/PG DN just move a couple inches and then stop? Unless StepConf 'does' something in file I'm not overwriting from my previous working system.

Again - thanks in advance for any suggestions... I know I'm not the quickest getting back, I have a part time job in my retirement which is starting to occupy me more than I like.

Arden

This is the only place I noticed it set true:

                # for encoder pins
                elif widgetptype == _PD.ENCA:
                    #print"\nptype encoder"
                    halsignallist = 'hal_encoder_input_names'
                    humansignallist = _PD.human_encoder_input_names
                    addsignalto = self.d.halencoderinputsignames
                    relatedsearch = [_PD.ENCA,_PD.ENCB,_PD.ENCI,_PD.ENCM]
                    relatedending = ["-a","-b","-i","-m"]
                    customindex = len(humansignallist)-1
                    # check for a thcad encoder
                    if "Arc Voltage" in pinchanged:
                        self.d._arcvpin = pin
                    elif self.d._arcvpin == pin:
                        self.d._arcvpin = None
                    if self.d._arcvpin and self.d.frontend == _PD._QTPLASMAC:
                        self.p.page_set_state('thcad', True)
                    else:
                        self.p.page_set_state('thcad', False)

 

Thank you! Worked perfectly

You might also want to consider servo drives from Delta, Rexroth, or others that support direct connection of the linear encoders to the servo drive for full closed loop operation.  This is combination with absolute encoders on the servos is how I think most new machines are doing it...at least the ones I have seen.   They could be controlled from either Mesa or with Ethercat.

You can just replace the private_data.py file in /usr/lib/python3/dist-packages/pncconf with the private_data.py that is attached to my post. I would backup the original file first just in case.

Well MesaCT doesn't support QTPlasmaC at the moment. I have done some work on supporting it but haven't heard from JT if he's interested in bringing those changes in if I make a pull request.

Nice effort! How would one apply the changes to get 7i95t support in pncconf?

What are pros/cons of using pncconf vs mesa CT? github.com/jethornton/mesact