Is there any way to have the PocketNC communicate with other devices programmatically?
I know there is no obvious I/O.
Does any linuxcnc compatible USB I/O work with the current firmware?
Or is there a way to send/receive at least single bit info to/from Kinetic via the web interface?
The UI communicates via WebSockets with a web server running on the BeagleBone inside the Pocket NC. Any external device on the same network can communicate the same way (so it could be commanded to do anything the UI can command). Sending information from Kinetic Control to an external device is a little more involved, but can also be done. Custom M codes is what I would suggest. You can put executables named MXXX (where XXX is a number between 100 and 199 that isn’t already being used, see /opt/pocketnc/Settings/mcodes) in your ~/mcodes directory and your G code programs can call it directly with up to two arguments P and Q. See M Codes.
Well… I’m a bit reluctant to explain, because it’s such a hack, but meh.
So at work I have to test mating repeatability of some radio frequency connectors, including 4 axis misalignment. My boss bought a manual xyzr stage and as we started thinking of the actual setup, and I was like wait a minute, I might know something infinitely better.
I can remove the spindle from the PocketNC so I have an ER40 collet from both sides, in which I can secure the two connectors with the cable going out the back.
This way I can automate the whole measurement with repeat movement, sweep through values of different misalignments, etc. I can write very simple g code for that.
The only think I need is to tell the measurement instrument when to measure. Ideal would be both way, pause/continue timing, but I can do with one way. E.g. PocketNC signals that it’s done with movement, and waits for some predetermined time while the measurement is running. Or the other way is fine too, I can do a measurement and signal from the instrument it is ok to move and wait predefined time for the PocketNC to do its thing.
It’s definitely an avant-garde solution, but I feel there’s even scientific paper potential in it.
It sounds like you could implement an M code (this can be an executable of any kind, so pick your language) that triggers the measurement and waits for a response. You could use something like ZeroMQ to communicate or really anything you want over the network. If you want something lower level such as triggering a GPIO pin, you’d have to get into the Beaglebone’s GPIO pins to wire it up.
Yeah, I did that with the 3d touch probe integration, I was just wondering if there’s an easier way. The M code seems to be better, as I run into difficulties trying to do HAL modifications and realizing that lot of those files are code generated on the fly instead of being static and it’s a whole different can of worms. If I can just drop the execs in place and use the M code that’s wonderful.