Advanced Search

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.

Hi, I did try it but did not work.

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

I tries the same operations in an anther compact mini itx system with i3 processor, it just worked fine.

Might be some network issue, due to the realtek nic driver.

Thank you,
Antony.

ffffrf wrote:

7. MOST IMPORTANT: so I have tried a traveling steady rest - the problem is, all of the tools have slightly different Z offsets (imagine a R handed 55 deg insert tool vs a parting blade - I guess I could solve this by having even more customized tool holders such that the actual cutting point of the insert of each tool type are all exactly lined up to the guide bushing, but I found this hard to do in my previous project which is why I was trying to pursue the W axis method (in addition to it being useful once I create the Y axis
 

I don't think you're gonna be able to get every tool exactly on the same Z point using separate tool holders.  But you can certainly set a Z-offset for each tool even without the additional W-axis.  You mount the tools as close as you can to some Z-point, and then set a Z-offset for each one to get them spot on.

The only thing a separate W-axis + fixed location bushing would help with would be getting clearance for tool changes without having to pull the partly-machined part back through the bushing.  Although now that I think about it, that'd be a pretty good reason to have one...

My ramblings about loading the stock was meant to get you thinking about the stock remnant.  Even if your Z has 12" of travel, you won't be able to cut whatever stock is inside the headstock/bushing once the new Z spindle nose is up against the back of the headstock.

Even if the bushing is only 1"-2" long, if it's mounted in the old headstock you can't cut whatever length the headstock is.  The Taig headstock looks to be about 4" long.  Add ~1" for a pulley to power the rotating bushing... so 5" long.

That's 5" of waste for every 12" piece.  If you use 18" stock it hurts less, but about 1/3 your stock simply can't be machined because the sliding headstock runs in to the back of the fixed headstock.

I suggested a traveling steady because you could build it very, very short, but still have a powered bushing.  The steady frame gets bored in place (as in Andy's vid) for a couple of AC bearings, and you make a bushing carrier 'spindle' which is just barely longer than the bushing.  The frame could even have a mount for a small servo built in.  If you get the whole thing down to 2" long, that's WAY less waste per piece of stock.

If you aren't keen on a traveling steady mounted to the X/W carriage, making a new - really short - fixed headstock would cut way down on stock waste.

hmm linuxcnc 2,9 doesn't have the hal_bridge component nor a way to use it.

That may be why it wasn't working too

Could probably get it to work in 2.9, but it would take some experimenting.