Advanced Search

sk_linuxcnc wrote:

i want the A axis to be rotating continously at a given feedrate.
and X to perform back and forth motion (based on the material width that i have, so that i can acheive a side-by-side layup of the material) the material parameters are mentioned on the above reply of mine.

Do you want A-axis/spindle rotating at continuous speed?

Or do you want it rotating at a continuous material linear speed? i.e. RPM slows down as the number of layers increases?

The few commercial winding machines I've seen appear to have torque-mode drums and an encoder on the material in-feed.  Think encoder wheel with a tire pressed against the material at the infeed guide.  I believe they are in torque mode to ensure that winding tension is constant regardless of number of wraps.

I don't know all the programming, but the infeed encoder RPM value could be connected to the drum/spindle PID to slow it or speed it up.  And the position value would be used to move the guide shuttle based on a material diameter formula.

Not really G-code stuff, more like PLC stuff.

Hi,

As long as a unsupported driver is close to a excisting driver nr, we can write some code for it so it works.
I am not very familiar with servo's, but beckhoff EL- stuff is not that hard.

Just order it, no worry's. We are here to assist.

Hi,

will this version from your repository control an real machine with ethercat servos?

You may run the machine on it, but it's not for production machine as it still has bug's.
The halcore has no home sequence etc. The version is just for testing purposes.
However i have a full backup for you, if you want to test it.

in the previous videos there was an tool direction that i could use to control the tangencial axis, is this avaliable in this version?
Yes, this works. You can simple turn it on or off as i remember.

As i am quite busy now, can we just not hack lcnc to run a axis and run blending for xyz?


 

Understood, Here's the lines where I suspect may be problematic, these are all after the touch-off:
#<touch_result> = #5063
#<calculated_offset> = [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]
G10 L1 P#<tool> Z[#<calculated_offset>]
G43
(DEBUG, Return to original tool-tip position using new z-offset: #<local_start_x> , #<local_start_y> , #<local_start_z>)
G53 G0 Z[#<_ini[VERSA_TOOLSETTER]Z_MAX_CLEAR>]
G0 X[#<local_start_x>] Y[#<local_start_y>]
G0 Z[#<local_start_z>]       <

---

LINE 244

The last line above is line 244.

The G53 call I have as -5 in my ini file. Which is an absolute call as I understand. The local variables are just that and
do not change when the sub runs.
The calculated_offset is consistent throughout the sub so that can be ruled out, I believe?
That leaves these two lines:
G10 L1 P#<tool> Z[#<calculated_offset>]
G43



 

Aciera wrote:

Not sure if this applies to your setup but classicladder does not seem to work with [HAL] TWOPASS = on

Classic ladder works on both my machines with TWOPASS = ON

2.9.3 on mill, and 2.10 on lathe.

Maybe the loadusr line needs to be in postgui.hal?

One thing to be aware of is that using motion commands with any other axis letter than XYZ causes the motion planner to fall back to one-line-look-ahead. This is not a problem if the motion segments are long enough but can cause jerky movement for short segments.

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.

The read ahead will start ingesting gcode again as soon as the touch off is completed and as soon as it reaches a command that would violate a limit the program will abort. This is happening well before actual execution of the queued motion commands.