has somebody a exemple how to connect external offset to real machine?

Hi,

I installed external offset branche. But how to connect the external offset to real machine?

Hi

Both rodw and myself have used the eo branch for plasma machines. I never could get the it to work well enough for THC but YMMV. I am still using the eoffset_pid.comp when cutting to follow the torch height corrections generated by a normal hal pid.comp. The eoffset_pid.comp compares the z feedback position to the z position commanded at the start of the cut (stored in a floating point sample and hold component) and passes this to the motion.comp as an offset so I don't get following errors. Dewey has extensive documentation and examples of how to use the eoffsets branch. The interface is very similar to a jog wheel (MPG) interface.

I am assuming that you are trying to be able to jog the Z axis while cutting with some kind of THC? You can do this without using the external offsets branch but it requires a lot of hal logic. Can you build your own hal components? A few custom ones make this a lot easier. The easiest way to do this is using the external offsets branch.

John

Hi John,

Thanks for your input.

If you use the eoffset_pid.comp your actual screen is correspondenting with actual torch height at the moment?
If so please tell me how to do this on real life machine. It will spare me weeks to find out.

How to pass a offset to the motion.comp, that is what i was looking for yesterday night. Then your screen is currently updated
with real life offset's that is fantastic !!

I was struggling with the thcud component. But at this moment i can compile new component's and i understand the logic about it
more. I always change the .comp name to .c when i am programming. The the program looks like c. Much better to understand.

I think the easyest way is to make a fake joint axis for a floating component. We have 9 axis, so one can be fake. Yesterday in the hal section it worked for 3 minutes. But later i changed some things, and i was lost... So i will try it again.

It would be great if you want to tell me how your current connections in your machine are. I can look at it and
maybe get things working. If i read about it on the internet, maybe 3-5 persons on this planet have the linuxcnc plasma tried out
with external offsets. The documentation is very good written, but i miss practical i/o connections.

Grotius

You really should see rodw's code, it is much cleaner than mine.

Yes, my DRO's follow the Z axis movement when under THC. There is a small following error but that hasn't been a concern so far, everything synchs up at a velocity hold or the end of the cut.

Please find attached a drawing of my connections. I think all the net names and pin names are correct. I will post my .ini and .hal files when I go out to close up the shop later. Please do not try and use them, they are not ready for production work.

I think this should all be moved to the Plasma section to keep it together.

John

Grotius

Please find attached my .ini and .hal files that the external offsets branch. Please be aware that this version uses a modified eoffset_pid.comp left over from some previous experiments. The stock component will work just fine so ignore the pins that aren't in the docs. This really is a work in progress and even though I cut some parts with it today it may not work tomorrow.

John

Grotius,

There is extensive documentation of the external offsets included in various places. The man page for eoffset_pid is one place to start. It is created from the comments in the eoffset_pid.comp file.

This text file also has instructions for building a working system.
github.com/LinuxCNC/linuxcnc/blob/dgarr/...eoffset_pid/hpid.txt

The main connections are made in a "hidden" hal file that included as a library.
github.com/LinuxCNC/linuxcnc/blob/dgarr/.../lib/hallib/hpid.hal
It also has some very useful information in it.

So if you follow the instructions it is really very simple to build a working eoffset config. All you need to do is to make a copy of the sim which is what I did in the example posted earlier today. Then make a copy of the hpid.ini file in that folder that references your hal file created into that folder.

Then cut and paste each of your joints and axis settings into your new ini file tweaking the commented lines to suit your velocity and acceleration settings.

In your new hal file, just set it up for your joints and axis settings and your home and limit switches. Also include basic estop settings. Keep the config to the barest minimum, no fancy stuff. It will only take an hour or so to cut and paste your working config into the the new config files and get it homing and jogging.

Finally, in a secondary hal file loaded after HALFILE=LIB:hpid.hal item in your .ini file, there may be a couple of eoffset signals that need to be overridden.
As the docs say,

I think I called this file hpid_plasma.hal in my config

Don't do what John and I did and just try and implement the hpid example into an existing config. Take the time to copy a working config into a new one based on these instructions and only after you get it all going, copy the components back into your more complex system. Take heed of this advice as it will save you time in the long run. (John and I both learnt the hard way).

If you follow this process we can help as we will understand your config and you might also get support from the external offset developer. But you will not receive developer support if you do not follow this process. It will be easier for you as eoffsets are pretty stable now, my config changed quite a few times as the branch matured.

How to pass a offset to the motion.comp, that is what i was looking for yesterday night.

I think from memory the external offset pins appear under axis.N.xxxx not under motion.

I was struggling with the thcud component. But at this moment i can compile new component's and i understand the logic about it more.

Its probably worth mentioning at this point that the name external offsets comes becasue the offsets are external to the motion controller. eg. The motion controller knows nothing about them (hence they are external). There are many uses for external offsets and I think the dev team should be congratulated for making so many sims demonstrating various uses for it.

One example is using it for plasma torch control and its probably one of the most complex examples and most of the heavy lifting is done in a custom component that includes Z axis PID control using torch voltage as feedback. It was expected that this would be used in a Mesa environment where the torch voltage was measured by a Mesa THCAD (voltage to frequency) board connected to the spindle encoder input. However, there are many other ways to measure torch voltage but you'd need to work out the necessary driver.

The THCUD component is not compatible with the model described above as it is designed to respond to the up and down signals from something like a Proma THC to move the Z axis in a bit bang approach. This is in itself not supported in the external offset examples John and I have played with. Thats not to say that external offsets can't be used but you need to develop your own programming paradigm.

The next level of sophistication is the THC component. linuxcnc.org/docs/html/man/man9/thc.9.html which is also designed to deal with the Mesa environment described above. This is also a bit bang approach and struggles with thin material or corrugated iron.

The external offset is one method proposed to introduce PID based control of torch height based on measured torch voltage and embed torch height control deep within the Linuxcnc trajectory planner. There are other methods to adopt PID control others have used.

What needs to emerge is a standard PID based approach to THC that just works. When that is achieved in LinuxCNC, plasma control will be nipping at the heels of proprietory systems such as those sold by Hypertherm.

Hi Rod and John,

I god it working, amazing !!
It was a few hours programming work.
I had a little error in the home sequence to solve in my grotius program, had to use c.home(-1) on this linux 2.8 pre version.
Step by step i transformed the standard axis config to the grotius config. At this moment the sinusgenerator is working fine.

At this moment i try to write some code to enable / disable the sinusgenerator. And enable / disable torch up and down signal
for proma thc. After that is working i must make a real time modbuss driver to load in hal. My current modbus i/o over the
user interface is far to slow for thc correctoins.

I made a short video. external offset first test

Great to see a start. The only candidate I am aware of for real time modbus communication is the Mesa Uart
linuxcnc.org/docs/html/man/man9/hostmot2.9.html
but it requires a custom bit file. PCW wrote one for me for the Mesa 7i76e and there are some others for other Mesa cards.
forum.linuxcnc.org/27-driver-boards/3328...th-uart?limitstart=0