Advanced Search

Probably, but how old is that PC?

Is it a wireless keyboard? I've had those start that when the battery died.

Hello, I've been running LinuxCNC 2.7 for 8 years now and I've decided to upgrade to LinuxCNC 2.9 because it's a 32bit installation, and software support is no longer a thing, browser is barely working, no modern SSH keys support (cannot use github anymore) - so I decided to upgrade to LinuxCNC 2.9 by doing fresh installation.

The problem is that PC won't boot from USB. I used dd to copy ISO to USB - and it boots on my modern desktop, but it won't boot on that old PC.
Is it because ISO contains only UEFI and not MBR ? What is the solution here?

Todd wrote:

.... so no soft limits

Does this also happen when homed? Meaning, does it ignore soft limits?
-
The only thing similar i recall was/is when a jog key is held pressed then another jog key is pressed => releasing them both would result in machine continuing to move until another jog button is pressed. This was probably a few (maybe two) years back, and only happened on 1 PC. I was busy so i did not have time to do more testing.
Does the same thing happen, or does it happen with a single key?
To stop, does any other key work, or just the jog keys?
Did you test with another keyboard?
-
Old info, well very old, the PC's had in BIOS a setting for "typematic rate settings" where you could set how much a should a key be pressed till it starts repeating, then how fast should those repetitions be, and for how long those should persist.
Have not seen that in PC's for over 20 years probably.

No, not a common fault at all, i am sure i have over 80 Mesa boards (more probably) and none of them ever failed, and they are mostly on industrial machines, and all are in use daily, some are never switched off, for over 10 years. And most are on plasma machines, by far the worst machines for EMI/interference.
What machine is yours?
Did you disconnect the stepper drive when checking with scope?

Failed stepgen outputs are most likely due to a problem with one of the
the output driver chips. For stepgens 0..3 these chips are a 74ACT541 (for the + outputs)
and a 74ACT540 (for the - outputs)

Does the  step3- output work? If not, it may be a deeper hardware issue
(PCB or soldering issues) These kinds of issues are rare.

Bad step/dir outputs caused by driver chip failure  are not rare but usually
traceable to accidental contact  of the step/dir pins to a voltage outside
the 0 to 5V range perhaps during initial wiring.

Probably a lost cause, but just in case ...
Turned on my CNC and the Z axis did not move.
After swapping out the stepper driver found that the stepgen no3 on the mesa was not outputting any step pulses as shown on my oscilloscope. Direction pin was changing as expected.
Changed it to number 4 and all is ok.

Assume just a hardware / output driver issue.
Is this a common fault on these cards. It is at least 5 years old. It lives in a pretty protected environment.

At this point I only need 4 stepper outputs so can live with it as is.

I made a new PWM board to +/-10V.
Now with isolated power supply and the possibility of differential analog output. Now the groundings don't mix
 





ps:I saw one mistake, I forgot to bring out the ground for +-10v
ps: 

Yes. that's correct but looking at the parport driver,
you may be able to do this by inverting the desired
output pin by using the out-invert parameter.

linuxcnc.org/docs/html/hal/parallel-port.html

[This would have the advantage that it would likely  work in reset mode
(which doubles the possible step rate at a given base thread rate)

Would this change in the hal for parallel port pin 2/3 be correct?

loadrt not count=1
addf not.0 base-thread

net xstep stepgen.0.step => parport.0.pin-02-out
net xstep => not.0.in
net xstep-neg not.0.out => parport.0.pin-03-out

I am currently seeing a very serious problem with keyboard jogging on a fresh install of the current version of Linuxcnc 2.9, installed using the current ISO.  Occasionally when jogging using the keyboard it appears as if the jog key you press sticks and the machine will continue to jog long after you release the key.  Sometimes it won't stop jogging until you press a different keyboard key (what key doesn't matter.)  I have only observed this behavior when using keyboard jogging.  Jogging using the mouse to click on screen jog buttons behaves normally.  This is a very serious and unsafe problem.  I just updated the control on this machine from Linuxcnc 2.7 to the current version, and I had never observed this kind of behavior before.  I've already totally smashed one limit switch jogging before homed, so no soft limits.)

The machine is using the Axis UI, running on an industrial (fanless) i5 mini computer.  Latency seems OK and the UI is very responsive not laggy at all.  

Is this some kind of bug?  Could it be a Debian setting? 

If you feel like testing there is an alternative:

Keep line 330 (ie initcode = "") and add these lines after it:



This should initialize the interpreter with the currently active modal gcodes.

Will_cnc wrote:

Please let me know if you make any progress , I am planning on using two cia 402 motors for the tool changer but don't know where to begin.

I threw the problem at ChatGPT and got a promising response.  I've not had time to really work on it and test, but the AI Overlord suggests that carousel should be in counts mode, and connecting carousel.N.counts-target to the lcec.N.something-something-position-command is the basic connection.

I don't know about homing yet, but I don't think it's possible to get around the requirement to rotate the carousel until the index pin is triggered.

I've attached an A-axis probing routine - it's from PathPilot.  I think it's suitable for cylindrical stock along A, not really for prismatic stock.

I've not tested it, but it'd probably be a good starting point for someone to test/tweak and then submit to the ProbeBasic devs for inclusion in PB mainline.

2. Run the macro — it probes at A=0° and A=180° in Y, calculates the midpoint, and sets G52 Y to the center of rotation

For this to work the following must be true:

• You have some sort of TCP enabled, or
• You adjust rotational point to stock offset in CAM after probing, or
• You have very simple parts, with very simple programs, and
  • an internal macro/subroutine 'adjusts' the Z/Y positions for every single point in the program based on the probed offset.

I think the easiest way to explain why (I think) your proposal won't work is to make a diagram.
 


If you have TCP that takes care of everything.
If you adjust CAM after probing, that also takes care of everything.
But just probing and shifting Y will result in bad parts unless you're only machining at one A-position.

I didn't draw the other problem... but not only will features not line up, the part will orbit the actual CoR, which means at A90/A-90 the Z-position will be higher/lower than CAM expects it to be.  Maybe crashy-crashy.

The only reason to probe is if you're doing 2nd op parts and have to line up features with existing surfaces.  Even then you'll probe, adjust CAM (or TCP), and pray.

No skim cuts, no calipers, no manual offset math — roughly 30 seconds per part.

Or use a work stop that gets the stock centered enough to take care of a little excess material - roughly 1 second per part.

The cause has been identified to be a side effect of the bug fix mentioned above. You can revert this by finding 'gremlin.py' on your system (I sorry but I do not know where that is on a package installation) and change this
 

to this:

 

This will revert the bug fix.

I'll have a look at getting this fixed without regression.