Advanced Search

Fusion's LCNC standard post doesn't have a section for rotary-related M-codes, other than undefined clamp/unclamp.  Nor does it output incremental moves - appears everything is in G90.  So any rotary axis motion which requires switching between G90/91 won't be able to take advantage of ROTARY_MODULO = 1 without post modifications.

I looked at a few other Fanuc-based Fusion posts and none of them (including integrator specific posts) appear to have any M-codes or switch between type_1 and type_2 on the fly.  If newer controls are like my old Fanuc 21, you set the Type in the control and can't do anything on-the-fly.

I see you're still working on this in GH... I'll wait to comment more until the OP does some testing.

Spumco, thank your for explaining that, i did not think about more than one OP at all as most of what i do (99.9%) is one-off on plasma and engravers, lathe is still waiting patiently for the hydraulic chuck.
Sorry for the jump in.

tommylight wrote:

Did you try unhoming and then homing the A axis?

 

Tommy - 

Re-homing a 4th axis means losing the work offset for that axis, even if its really close.  Unless you've got an accurate high-resolution encoder directly on the rotary axis (not just the driving motor), there's always a bit of 'ish' until you indicate the rotary axis in.

I've got a moderate resolution encoder on my servo, the 4th homes to index, and it's using a name-brand zero-backlash harmonic reducer... but it's rarely perfect. The only way to get (mostly) perfect is to home then indicate the axis and set the A-axis work offset... and not shut the machine off or re-home the axis.

None of that matters if all you're doing is OP1 parts, but if you're doing OP2 (or later) parts and previous features have to line up with new ones, a dead-nuts A0 matters.

antonyvm wrote:

I have abandoned the idea of setting up the Linux Cnc in the nuc.

Thank you,
Antony.

Probably a good idea. I had an expensive i7 NUC die before my very eyes and Intel made ridiculous offers under warranty that required me to invoke the Australian Trade Practices Act provisions to get a refund. 

Yes, coupling of inputs often means a missing ground.

Note the the field I/O is completely isolated from the
logic (5V side)

Kind of where my thoughts where - to the periphery of the board the wiring is correct - I've strapped field-V to the inputs (input KEFG connector). What you've described I can believe with a broken track/open circuit component on the board.

Seems like interference from missing/wrong wiring/not connected grounding, or disconnect of the negative field power.

Did you try unhoming and then homing the A axis?
In case there is no home switch for A axis, that should just work and set the A0 wherever it is when you click HOME, and if there is a home switch it should just move up to the switch and home as usual.
In Axis GUI, unhome from the machine menu, or there is also the possibility of adding a VCP button to do both steps at once.

The easiest is master branch aka 2.10.

As the originator of this request, I've left my feedback in detail elsewhere, but let me summarize my request for this thread: After an hour or more of spiral carving with Fusion's linuxcnc postprocessor, I end up around A556200 (for example), then Fusion does G0 A0 to "reset" the rotary for the next op.  That takes many minutes of high speed spinning, and is totally unneeded.  I would like to skip this massive unwind.  This is a common complaint online, and the usual response is to use G10 to change the WCS offset before the G0 A0 but that has its own drawbacks.  Doing something similar in the G0 itself would be much more consistent across the machine's operation.  Yes, WRAPPED_ROTARY, but there are times when you don't want to use that.

Context: An old Boxford 160 lathe adaptation, using the (fabulous) Mesa 7i76e card (integrated FPGA/2-port/massive break-out of I/O/Steppers etc). Started too many years ago and been through various incarnations, LinuxCNC uplifts etc. Never really used in anger, but more for learning about LinuxCNC, in between juggling work, the wife and various cats. Now that I'm retired I can start to concentrate a little. A long winded way to say I think it used to work but now...

Somewhere along the way something has happened. I have push button controls for jog x+/x- and z+/z-, with the jog speed controlled by an analogue pot, From memory, this all worked. Then retirement hits and I get more time to play. The behaviour now somewhat peculiar. X+/- work as expected. Z+/- are more erratic. Turns out, through HAL-Show/Scope that I have z+ on 7i76e.0.input-08 and z- on 7i76.0.input-09.

If I activate (field voltage to input) input-08, the resulting waveform on halscope shows an erratic 0/1 value for the duration of the field voltage being applied. Once field voltage is removed then the signal on halscope reverts to a steady 0.

If I apply field voltage to input-09, then input-9 is shown high on halscope and input-8 reverts to the erratic 1/0 value whilst the voltage is applied to input-09. Removing voltage from input-09 and both input8/9 on halscope revert to 0.

The observation on halscope describes perfectly the observation on the machine - traverse in the Z axis is erratic to the point of occasional reverses of direction and/or stuttering of the jog.

Particularly as my fuddled brain thinks that when I last played with this this all worked, I'm thinking this is likely to be a hardware issue on the 7i76e card. I've quickly belled-out all other inputs and they appear to work as expected. This does mean I can re-wire to use an otherwise unused input, but this irks me.

Has anyone experienced anything like this before?, and is there a solution (e.g. a different bit-file for the FPGA?)

The nature of this is peculiar to my mind, that this is likely tied not so much to a IP fragment of the FPGA, but more likely individual hardware between the terminals on the board and a FPGA port pin. Particularly as the input-8 looks to be in someway coupled to input-9 I'm inclined to get the associated pins under the microscope and reflow the joints, but that's a job for another day. This post just to understand if anyone has witnessed similar and found a solution?

Regards,

Mike

with which version of LNC is it possible to use the hal_bridge component?

hi grandixxmo, any further development on the 9D S-curve branch?
what is the area of testing we need to look at.
If we can setup some direction, we will get multiple volunteers to help check the work that is already done.
-automata

You could, but you risk more damage if you accidentally connect the 5V  to a 3.3V signal.

Most likely the inputs of the 26LS32 has been damaged so the chip needs to be replaced.

This takes care and protection of the nearby plastic connectors with some kind of
insulation from the hot air gun heat (I typically use some paper sticky labels on
the green connectors)

Hi all. I have an open PR (#3969) that adds a new rotary axis behavior and would like input from people who actually use rotary axes. The problem it tackles is the long unwind: after a job that accumulates rotation, a simple G0 A0 takes minutes spinning back to zero. Related, CAM output of G1 A45 from A350 normally does the long way 305 degrees instead of the short 55, unless you use sign convention everywhere. WRAPPED_ROTARY exists but uses the input sign as direction, rejects values outside plus or minus 360, and does not wrap the DRO or 5423 to 5425 parameters, which some users find awkward.

The PR adds an INI flag, AXIS_x ROTARY_MODULO equals 1, mutually exclusive with WRAPPED_ROTARY. With it enabled the default mode is M26, where every absolute rotary move takes the shortest path. G0 A0 from any accumulated value goes the short way, no long unwind. There is also M27 which uses the sign of the input to pick direction and modulos values above 360. So A45 goes forward, A-45 backward, A720 becomes A0. DRO and 5423 to 5425 are wrapped to 0 up to 360. Internal motion-side position stays accumulated so stepgens, encoders and PID see no discontinuity. Multi-turn winding is done with G91 incremental, same idiom as Heidenhain IA+, Siemens, and Fanuc G91.

If you use rotary on commercial controls this should feel familiar. M26 default matches Fanuc rot_type 2 and Heidenhain M126 and Siemens DC. M27 matches Fanuc rot_type 1 and Heidenhain M127 default and Siemens ACP/ACN. The axis flag itself is the LinuxCNC equivalent of Fanuc parameter 1008 ROAx, Heidenhain shortestDistance, Siemens MODULO axis config.

What I want to hear: does this behavior fit how your CAM emits G-code, would M26 default plus plain absolute output Just Work for you or would you need M27 sections, are there kinematic configs (coupled 5-axis TCP, gantry rotary, weird mappings) where you think this would behave badly, and do you have test G-code you would like me to run through it before merge.

PR is at github.com/LinuxCNC/linuxcnc/pull/3969, original issue github.com/LinuxCNC/linuxcnc/issues/3902. Branch grandixximo/linuxcnc:rotary-modulo, builds clean against master. Happy to iterate on design if there are cases I am not covering. Thanks.