How do I read current system variable into my Gcode program?

More
17 Feb 2018 00:22 #106057 by waxelson
Rod,
1) Your suggestions have actually lead my co-worker to pursue an approach that just might work. He has created a routine solely in python to do all the axis control with MDI commands and calls it with a user-mode M command.

To monitor the angle of the rotating platform, he is reading in the cumulative angle, scraping off the decimal portion and multiplying it by 360 degrees. He has the platform alternating between a slow and faster speed depending on the current angle band and the Z-axis is hopping up and down at the same time appropriately.

His current version does not catch every transition and misses the end of revolution transition more often than it catches it. However, he is exploring ways to speed up the inner loop of his program to be more deterministic. It will never be "realtime" but if we spin our optics platform slowly enough, it just may be adequate.

2) The link to a user who created a custom component was very interesting. Even though he did not have it working yet, it seems like it was not that hard to do - better than recompiling a new version of linuxcnc anyway. We will probably look for a way to rewrite the "too slow python" code into a version that runs in a component that should be faster.

Thanks again,
Wayne

Please Log in or Create an account to join the conversation.

More
17 Feb 2018 02:27 #106060 by waxelson
Todd,
I just "discovered" ClassicLadder in the documentation. This looks like a very promising path for me.

I have spent many years programming PLCs and this implementation by Marc Le Douarain appears to follow the standard conventions closely. It seems to offer access to realtime parameters without complication or restriction.

Have you worked with ClassicLadder before? If so, any suggestions?
Wayne

Please Log in or Create an account to join the conversation.

More
17 Feb 2018 02:37 #106061 by waxelson
Todd,
I changed the scaling of the rotating C-axis to degrees and have WRAPPED_ROTARY = 1 set. However, it still does not reset the value to zero at 360 degrees as advertised. I must be doing something wrong...

Interestingly, if I issue a homing command with the AXIS GUI while the C-axis is rotating, suddenly the DRO does display correctly from 0 to 359+! If I stop the axis to home it properly, with the 360 to zero transition where I want it, the display goes back to the unhelpful cumulative total. Weird. Any idea what I am doing wrong?
Wayne

Please Log in or Create an account to join the conversation.

More
17 Feb 2018 09:25 #106068 by rodw

For the wrapped rotary to work the axis must be scaled in degrees. If it is in revolutions it won't wrap until 360 revs.


Todd, I went back and checked all of my settings. Wrapped Rotary has no effect if its intention to limit the position to 0-359.99 and wrap around to 0 again in master. Is this a bug or not?

Please Log in or Create an account to join the conversation.

More
17 Feb 2018 12:01 #106071 by rodw
Hmm, this might be almost done for you in Dewey Garrett's external_offsets branch.
github.com/LinuxCNC/linuxcnc/commit/a764...a6e1f1b32c348cd88112
He has a component eoffset_per_angle and a sim opa.ini that uses it which is a X,Z,C machine.
This config cuts polygons (by adding offsets to the X axis) from a program that simply draws a circle.

So it seems to me that all that Wayne needs to do is change the code so it puts the offset on the Z axis using his formula not Dewey's polygon cutter.

Please Log in or Create an account to join the conversation.

More
28 Feb 2018 17:04 #106722 by andypugh
I don't think that you can use Python here, as that runs in user-space and you need realtime coordination.

I think that the elegant way to do this would be with the external-offsets branch.

Then, in HAL, use a pair of "lincurve" components to calculate the up and down Z offsets.

Then switch between them with a mux2 component.

Here is something I mocked-up for crank grinding using this approach:

Please Log in or Create an account to join the conversation.

More
28 Feb 2018 20:10 - 28 Feb 2018 21:19 #106752 by Grotius
@Andy,

If you have a optical distance sensor with up and down signal, for example ifm sensor.
Why can't you in hal load a simple rt-module for following telescope mirror depending on sensor signal up and down?
It sound's easy but linuxcnc has no such a standard following component written.

In the comp section this can be written in a few lines. And the problem is solved.
For forum readers, the module's of comp are compiled real time software pieces that can be loaded in linuxcnc.
A example is THCud.comp. This is a module for plasma machine's who work with up and down signal of torch heigt controller.
The THCud.comp file is orginal a code looks like C code. After compiling you can load it in hal like : loadrt THCUD ....
The component basic written c code is very short. So a naked code can manipulate the axis to the mirror perfectly on sensor based input methode.
So if my explenation is not as good, please comment. Then i can make a example.

In about a few weeks i make a "load rt updown" hal file code example for leading the axis you want up and down. Following up and down input signals. For my project it is also neceserry to make this item available in most naked version. My wife is thinking what about me?

Also it has the optional tuning factor's. The rabbit picture of Gmocappy... Hihi
Last edit: 28 Feb 2018 21:19 by Grotius.

Please Log in or Create an account to join the conversation.

More
05 Mar 2018 21:38 #106981 by andypugh

If you have a optical distance sensor with up and down signal, for example ifm sensor.
Why can't you in hal load a simple rt-module for following telescope mirror depending on sensor signal up and down?
It sound's easy but linuxcnc has no such a standard following component written.


That is what the PID component is for.

Please Log in or Create an account to join the conversation.

Time to create page: 0.137 seconds
Powered by Kunena Forum