Advanced Search

Hi Axemas,

really appreciate the steady progress you’ve been sharing, great demo video! It’s clear a lot of careful work is going into this, and it doesn’t go unnoticed.

The lathe features especially the polyline workflow alongside G71/G72/G73 look genuinely promising. That earlier preview video sparked a lot of anticipation on my side, and I’m still very excited.

Have you had any time to push this further since your last update, or did testing surface any tricky blockers? No rush at all just curious where things stand.

Thanks again for keeping NativeCAM moving forward. I’m really looking forward to the next steps.

greetings

Tom

Drafted a new PR, this basically does the G10 for you automatically instead of spinning too many times, maybe this is better for real use cases without actually having to change gcode/post, rotary modulo is orthogonal to the need I'm seeing here, don't worry about the failures the building bot is temporarily broken cause of Ubuntu snap store is down.

github.com/LinuxCNC/linuxcnc/pull/3990

I think rotary module is an improvement over wrapped rotary, but if post changes are a no no, then interpretation has to change, although a smaller change, the interpretation inconsistency might get caught in some edge case. I try to catch all I could think of in the PR.

It's been reworked by YangYang, 9D branch will probably be abandoned, in favor of whatever YangYang comes up with, it's loosely based on my work form 9D branch. What we are working on now internally, which I was going to talk in the next meeting, is a pre-processing library, as we are testing Yangyang's TP2 internally before release, we found that the last few jerk spikes were caused by segments that are shorter than a cycle time, there is just no time to do proper calculations on them, the pre-processing will be a toggle in the INI file, the library will be called Liscio, also renaming Ruckig to Scatti cause that's what we talked about with smoe in the mailing-list, and YangYang can't pronounce Ruckig 
Anyway Liscio will create a smooth path with NURBS, still early stages, would love some test gcodes from the community, so we can kink out most issue internally before release.
There is precedence commercially with Fanuc I believe, they are doing similar work, probably others as well.

PCW wrote:

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)

OK. I won't risk.

I'm watching videos with notebook repairs, so i saw there how they protect the plastic parts from melting.
I hope i wont fail.

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