IO interface with Arduino over Ethernet

My code is modified from the original project from this thread. I use the esp-8266-1, in an Arduino uno (which will eventually be a nano - when I can find a suitable enclosure to fit the hardware buttons - but that's another struggle)....

The difference in my project, is that it does not re-assign input/output pin mapping on each packet exchange. My project sets up inputs and outputs one time in the setup function. I am not sure how much time is gained with that - but I can't see it being so latent to notice without gauging with a scope or a timed circuit.

The second difference in my project from the original posting on the thread, is my encoder handling procedure. I send the difference in movement of the MPG dial encoder to HAL, instead of updating the A/B hardware pins into HAL copying the Arduino hardware pins. If somebody was really wrenching fast on the encoder, faster than the latency of the processing in packets - my code only sends the difference in position from the last packet - VS - copying each signal from the encoder.

I only intended to use this project to toggle all the user input MPG jogging buttons, run, stop, home, zero. All the basic manual navigating & targeting to setup the machine. If code was not executed in the time it takes to send 1/2 of a packet and transfer that information to handle other cycles - it would be so small, I would again need a scope to measure that difference in time since it could be in microseconds. The speed of my hand & eyes to press emergency-stop is a whole lot more time, than it takes to transfer that signal from the Arduino button - through WIFI, to ethernet - into HAL.

If by comparison to a MESA card in terms of speed of I/O from motor positioning encoder feedback, the MESA card would be faster. I can't give you any statistical figures on tests for any of that since I do not own any MESA cards. For the last 9 years I've done everything I needed to do with dozens of machines I built - and 2 Bridgeport Boss retrofits using only parallel interface cards and a heap of wires, switches and lights.

DocStein99 wrote: The second difference in my project from the original posting on the thread, is my encoder handling procedure. I send the difference in movement of the MPG dial encoder to HAL, instead of updating the A/B hardware pins into HAL

Sending absolute counts would probably be more robust, and is what the Mesa and Pico cards do. The wheel-jog inputs to LinuxCNC expect a counts value, so this also save HAL complexity.

Well that's interesting. Again, I don't know how the Mesa or Pico cards work - but I assume they have their own assembler compiled drivers that lace directly into HAL pins, using whatever they do to pass data between the devices. I don't know how fast the data is passed between Python and HAL, I just assume it's probably measured in machine cycles faster than the time between a step pulse.

DocStein99 wrote: Well that's interesting. Again, I don't know how the Mesa or Pico cards work - but I assume they have their own assembler compiled drivers that lace directly into HAL pins, using whatever they do to pass data between the devices.

They work reasonably straightforwardly. The LinuxCNC HAL driver reads register values on the FPGA on the card through PCI, EPP, SPI, Ethernet etc. These numbers are converted to "engineering units" in the HAL driver. Also, most encoder counters are extended to 64 bits to make wrapping unlikely.
This is the code that reads Mesa encoder values:
github.com/LinuxCNC/linuxcnc/blob/master...tmot2/encoder.c#L862

And, if you care, this is the vhdl that defines the encoder on the FPGA
github.com/LinuxCNC/hostmot2-firmware/bl...r/src/qcountersf.vhd

andypugh wrote: This is the code that reads Mesa encoder values:
github.com/LinuxCNC/linuxcnc/blob/master...tmot2/encoder.c#L862

And, if you care, this is the vhdl that defines the encoder on the FPGA
github.com/LinuxCNC/hostmot2-firmware/bl...r/src/qcountersf.vhd

Ok, well you've just gave away all the magic. I was a little mystified before, but now I can see the code is as simple as writing an ansi .C class object - that uses the same digital standard for all the other devices - yes, it is quite straight forward (to me).

The examples are a very important to me - thank you for pointing them out. I was actually interested in knowing how these signals were transferred and how I could design my own hardware interface to solve the comparability struggles I go through each time I make another system. I've wanted to make my own remote step/direction output board to merge directly to the motor driver, and get rid of the 4-6+ bulky long wires that had to route through the cabinet to the motors.

DocStein99 wrote: Ok, well you've just gave away all the magic. I was a little mystified before, but now I can see the code is as simple as writing an ansi .C class object.

Yes, it really is quite easy. It is easy because John Kasunich (and others) made a really good job of making HAL extendable, and Seb Kuzminsky made a really good job of making Hostmot2 interfaces abstractable even though when he started there was only PCI and EPP.
At this point in time I think that I have written about half of the Mesa to HAL interface code, but that was all made possible by others designing their interfaces well. The first C-code I ever wrote was the Mesa card LED HAL driver.
LinuxCNC is _meant_ to be easy to code for.

Linux is a whole lot easier to code - compared to MICROSOFT! I held a career as applications engineer in Visual Studio, processing data in SQL servers, and telephony SIP voice streams. Windows has so many layers of permissions, grants, rights to access admin for each and every move - it's evolved to take the fun out of coding and bring misery of security! I can't go on about how many bible sized books I studied to try and learn how to write a hardware device driver in windows.....

LinuxCNC is easy after learning as much as I have from using it and studying all that I could about how each and every signal is generated, toggled and passed through all the way down to the motor itself. I bought plans 12 years ago on soldering my own stepper driver board using logic gates and tip-120's, since it was important for me to know how to make a motor move from the push of my keyboard button, all the way down to the electric passed through those coils.

I am interested in helping linuxCNC as it has helped for me, in the past. It's a powerful collection of tools limited only by imagination, really. Remote controlling motors, wireless, the list is endless.

It took me a little poking around to find this thread, was kind of frustrated when it took me a little searching around. I figured since the last time I did a setup, someone surely added a feature to toggle i/o pins through a tcp socket. It's a real drag lacing up dozens of wires to make a hardware control panel.

DocStein99 wrote: I figured since the last time I did a setup, someone surely added a feature to toggle i/o pins through a tcp socket.

linuxcnc.org/docs/2.7/html/man/man1/linuxcncrsh.1.html

andypugh wrote: linuxcnc.org/docs/2.7/html/man/man1/linuxcncrsh.1.html

This is a useful feature for me, absolutely. But the cnccrsh has no actual user interface, which makes jogging blind without readouts or anything else. That feature would be great to just design the user interface in Windows to actually control the hardware linux side, on anything else.

Im looking at ordering a stm32f103c8t6 and a enc28j60 network adapter to see how much speed i can get for encoder counting... The arm cortex-m3 runs at 72mhz and it looks like it can be programmed from the arduino ide. I'll let you know how i go.