Coordinate systems exposed in HAL?

On my project machine, I use something that resembles a coordinate system but it's built in Python, and that was done just to get everything going and get it working. I don't program in Python, a friend handles that for me but I pretty much direct the project and handle all of the hardware stuff. The actual movement between axis' is not coordinated as it would be using something that follows typical 3-axis coordinates. It's basically 2 independent axis' that move back and forth but there are several offsets applied and stacked. It was always the intention to apply some sort of relative positioning that is native to LinuxCNC.

Now I'm at a point where it's getting a bit complicated to continue applying offsets in Python as I have been. I hadn't fully looked into it but I assumed a relative position was exposed in HAL in some way but now that I'm really looking at it that doesn't seem to be the case. I believe I thought the joint would always read a relative position after it was set by something and the axis would read the absolute position, but it seems that's not the case. My mill joint and axis always seem to read the same even when relative position is active. Now I'm wondering if the relative positioning and what not is a function of the Gcode interpreter or something else.

What I ultimately want to do is build a 2D coordinate system X,Y. Where X is a belt driven stepper axis and Y is a roller that measures an externally driven encoder. I don't have a use for relative positions on the Y axis, but X axis would be something similar to a work offset on the X where I would call an absolute position value a relative "0" and then work from that. This is something I already have going, but it's python working off of absolute values and applying some math to set up a limited travel range.

I think I figured that Halui handles this. Looking at it, halui is pretty bloated for what I'm doing. I think the best thing I could do here is have my friend write a component that would handle positioning.

andypugh wrote:

What do you mean by " I use something that resembles a coordinate system but it's built in Python,

I find this pretty difficult to explain, If you have a mill you're going to find an actual position based on the homing sequence, then you are going to set up coordinate relative to a workpiece on a table and call that "0" on the X,Y and Z axis. If your machine consisted of 2 typical X axis', and 2 "virtual" Y axis', did not use any Gcode implementation, things would have to work a bit differently.

I find an actual X position exactly as you would on a mill, but after this the 0 offset and travel range are set/limited by simple user inputs. Calculations are applied in python to set these ranges and limits. I had to shorten up this clip (because internet) so you probably can't get the full idea of what this thing does. There is a camera under that hood, and another hood/camera/axis underneath the web that is flashing a strobe while it is taking a synchronized image, the coordination of that image being advanced and retarded against an encoder and external index sensor is the "Y" axis. The Y axis is actually straight forward.

It's the 2 X axis' that are difficult. If you imagine that the width of that web can vary from use to use. The person using the system is basically setting up the x coordinates and travels by just entering the width of the web. The configuration of the machine's UI dictates whether to base the travel ranges on either a web that is always centered in the machine and width would vary from the center out, or the web can always be justified to either edge of the machine the configuration would accept a static "offset" value and vary the travel range toward the opposing direction. This requires something different than LinuxCNC would typically be configured for in standard UI's, my UI is built from scratch. The "rules" for setting up these travel ranges from the UI are written in python.

I'd expect to find (which there may be, I just can't find it) a comonent that can accept an actual-position input and allow an offset value maybe a position "zero" bit, and output a relative position based on that. I could probably work with that. I read the man for motion, I see that some of this is included but I can't quite figure out if it's suitable without any Gcode implementation. I don't use any Gcode since I'm not running any predefined programs on this thing. If there was a straight forward HAL approach I would probably just work with it/

I spent some time writing the rules for a component that would handle positioning specifically the way I'd use it. The friend that I work with on this can hopefully write a component to do this positioning, Likely the best approach based on how specific this winds up being.

Why not use the LinuxCNC coordinate systems?

Because above

What is LinuxCNC doing in this system, if anything?

A whole UI built in GladeVCP, a python interface, mesa drivers, HAL is a pretty big thing, damn near everything other than Gcode interpretation, and obviously relative positioning

www.dropbox.com/s/66sjfddnhj5u0mg/Video%...2016%20AM_0.mov?dl=0

Correct me if I'm wrong but this is a web fed printing press and you are aligning the opposing print images?

I think it could be a candidate for the external offsets in Master branch so that one axis was positioned based on the offset from the encoder. I suspect a component written in C might be required. This would give you real time adjustment rather than a user space python program that is not guaranteed to be real time.

If you install master branch, there are some sims under the axis config that shows how to implement the offsets. also the master/development branch for motion includes documentation for the external offsets.

Pretty cool idea.

rodw wrote:

Correct me if I'm wrong but this is a web fed printing press and you are aligning the opposing print images?

I think it could be a candidate for the external offsets in Master branch so that one axis was positioned based on the offset from the encoder. I suspect a component written in C might be required. This would give you real time adjustment rather than a user space python program that is not guaranteed to be real time.

If you install master branch, there are some sims under the axis config that shows how to implement the offsets. also the master/development branch for motion includes documentation for the external offsets.

Pretty cool idea.

Yeah, that's a printing press. The machine is a viewing system. That blur of a web running at 1000fpm becomes a crystal clear image that can be navigated in the X and Y directions. I do agree about RT and I have been meaning to move this out of python as soon as I could figure out what method to use. Honestly it does not matter that much. Everything is based on the absolute position which is a HAL function, python just requests a new position or tells LinuxCNC to jog at speed. It's basically like jogging your mill around, python is just figuring out how far to allow you to move it, and that limit is a static value. The encoder and the event that it triggers is the main RT concern and all I really do with that in Python is interface the GUI which is basically just using a hal Vscale to change the encoder position that the event happens on. There's a reasonably extensive HAL logic file with with comparator's, oneshots, and2's to the point I had to draw it as an electrical diagram with Kicad to follow it.

Which actually reminds me, when I wrote that hal file and drew it in Kicad I kept thinking. A HAL Kicad library with components represented by electrical symbols would be a hell of a thing.

andypugh wrote:

blazini36 wrote:

I spent some time writing the rules for a component that would handle positioning specifically the way I'd use it. The friend that I work with on this can hopefully write a component to do this positioning,

I don't think that this should use Python, but it is a good candidate for a custom HAL component written in C.
The reason for this recommendation is that doing it with a C HAL component keeps everything in the realtime realm. Python (even Python HAL components) are not realtime.

Sending the target positions from Python / GladeVCP however is entirely reasonable.

Take a look at the already-existing offset HAL component, making a modified version of that shouldn't be too hard, even for someone unfamilar with C.

Manpage: linuxcnc.org/docs/2.7/html/man/man9/offset.9.html
Source Code: github.com/LinuxCNC/linuxcnc/blob/master...mponents/offset.comp (half comments, a few lines to define the HAL pins and 2 lines of actual C code to calculate the pin values.
.comp file format docs: linuxcnc.org/docs/2.7/html/hal/comp.html

Actually looking at rodw's suggestion, the external offsets in motion looks like it could work reasonably well (any ideal if this was available in the 2.8pre 7i96 branch?). I still have to reconcile limiting travels though, but this more or less answers the question of the post, since the "offset" becomes the relative position's 0. This is more or less what I think I was looking for, but after figuring out the usages of a specific component from scratch it's really the best way to go. I use an instance of the offset component in my hal logic file but it's a pretty simple static usage. Using the offset component or motions new external offsets still requires alot of Python intervention.

My friend, and almost every programmer I've ever spoken to knows more and would prefer to use C. He actually had to learn python to help me with this. Writing the component would be easy for him if he can understand the logic I wrote in the notes. We went in the wrong direction in quite a few places with this, but that's mostly due to me trying to learn the ins and outs of linuxCNC. A really good component with specific uses would probably strip out half of the main Python file. I designed the whole GUI to be set up by an operator and configured 100% from the GUI's submenu, so a component to facilitate that would make things easier. Idea is that the hal configs should never need to be touched again once it's deployed. Mostly everything currently works, it's just a real chore to get the last few things working because of conflicting python programming.

Looking at the UI you can kind of see what the issue is with LinuxCNC's standard positioning methods, everything else is flexible enough to make things work without too much trouble.

Writing components is LinuxCNC's best kept secret I think. There are heaps of code examples for the C programmer to follow
github.com/LinuxCNC/linuxcnc/tree/master/src/hal/components

Yes, the external offsets are now part of the master branch base code so its available to any linuxcnc application. Its hardware independent.