Advanced Search

OK since this has gotten some interest, there are two methods of using hard stops for homing without messing with the drives at all, for DC brushed motors:
1. using hal sensors wired to inputs (be it Mesa or Pico or parallel), more windings around the sensor = more sensitive
2. using REED switches wired to inputs ...., again more windings = more sensitive
-
There are two types of hal sensors, those with variable output and the on/off type, latter is easier to use for this use case.
Sensors should be wound with only one motor wire, not both.

NWE wrote:

May I ask, what use case requires adjustable home_search_vel?

+1

May I ask, what use case requires adjustable home_search_vel? Sorry for my ignorance.

tommylight wrote:

There are reasons why brushed DC motor powered machines have two sets of limit switches, one set does normal limiting while the other set is "extreme limits" that will cut all power to motors.
Brushless DC and steppers motors have no need for such measures as if the drive fails it usually causes the motors to lock and burn quietly, if all other safety measures fail.

Normally, yes. To date I've seen two Ursviken Pullmax press brakes. Both had DC servomotors all over and a shocking lack of hard limit switches. They are heavily built and very precise press brakes, but given the way the old controls were set up, the wording in the manual, and also a reprimand I once received from one of their dealers when I asked how to initialize the controls, I get the idea the users were expected to hire Ursviken techs to 'repair' the machine if any axis so much as ran into a limit switch. I consider the old Ursviken controls quite difficult to clear limit errors.

Instant runaway is certainly one of the possible hazards of brushed DC servos when the h-bridge shorts over one side. However, I have not yet seen that happen, but I will not say it can't. The few failures I have run into so far, the h-bridge was shorted completely and popping fuses instantly. I think what happened in those cases is the closed loop feedback detected the servo was a few encoder counts too far off and tried to correct by reversing the motor (by switching on the still good side of the h-bridge), causing a short and blowing fuses. Theoretically, the servo might run away far enough, fast enough to cause a positioning error, disabling the servo amp (and switching off the h-bridge) but with power still applied to it, and with half the h-bridge shorted, the motor could then run away uncontrolled.

Any way, I don't like brushes. Back when I was busy with smaller repair projects, I messed with sooo many brushed DC motors that needed brushes which were next to impossible to match up. I usually filed down bigger brushes to fit, but that is messy work. If I'm working on a project like this and have any reason to suspect a motor is weak or otherwise worn, I strongly recommend my customers to go with AC servos if possible.

Hello Guys 
For long time i trying to find any way to control the HOME_SEARCH_VEL for the calibration cycle, i'd like to link the signal to a knob that control the rapid speed as well 
Im not expert, im not sure if i got to create a  HAL thread to link the HOME_SEARCT_VEL
your help is appreciated
Regards
 

I guess if you wanted to be really safe, you could loop back a free output
to an free input and put a watchdog signal on the output and use LinuxCNC's
watchdog component to trigger a fault if the output ceases to toggle.

PCW wrote:

if the probe signal goes through multiple hal components, they need to be addf'ed to the
servo thread in processing sequence or you will add additional pipeline delays.
 

Ah!  I think I guessed that order was significant, I didn't realize it was official.  Or at least "official".
That leads me to a follow-up HAL question (sorry for the thread drift).  Can I add the same component twice?  I mean, with different names, so I don't need one central "and2" with a dozen instances, I'd rather have each function/section add its own components as needed and in the right order.
If not, getting things in the right order across all components might be difficult.

Do the rest of my ponderings still apply, since I'm using dbounce and it delays the signal ?

Thanks!

I'm trying to load Linuxcnc on to a new computer and getting and this error, it works on one computer but not the other. here are the error report and HAL file. 
 

There should be no more than 1 ms in hal/LinuxCNC lag at a 1 ms servo thread rate.
if the probe signal goes through multiple hal components, they need to be addf'ed to the
servo thread in processing sequence or you will add additional pipeline delays.


That is, the sequence should be:

hardware read
process-0
process-1
process-2
motion
hardware write

PCW wrote:

You would normally choose a latch velocity low enough that the 1 ms (max) sampling uncertainty causes a minimal position error when probing.

I pondered this truth at one point recently, and did some experiments.  I wondered if the "signal lag" due to communications and HAL processing (I needed to add a noise remover[1] and mux[2] to my probe inputs, so I was at around 10ms of lag at the time, assuming each HAL component added at least one servo-loop of lag) was reducing precision here and causing the motion to continue past the actual probe point, and wondering how fast I could probe without destroying my toolsetter (testing delayed while toolsetter repaired) limited by this lag and deceleration limits.

My first findings were that the HAL lag was significant and I had to limit "fast" probing to 6in/m or so, which made me wonder: I have the axis accel limited to reduce overshoot at the tool[3], but is there a way to override that when probing or homing so I can stop faster?  Does homing use the joint accel limit instead of the axis accel?  Can accel be changed by gcode or HAL?

My second findings were thus: if I probe towards and capture the result, then probe away at the same speed and capture *that* result, and average them, I get results that are more consistent and less dependent on probing speed.  If this makes sense, one could drastically reducing probing time, but "probe slow enough" is just so much easier

Does it sound like I understand what's going on?  Is there any value in pursuing the dual-probe-average method?

Is HAL lag impacted by the order in which stuff is listed in the config files?  It would suck if I were calculating the probe signal just *before* reading the 7i76


[1] Aluminum extrusion CNC with 7i76 here, and sometimes the ATC actions vibrate the frame enough to trigger the toolsetter.  Bad for normal operation, good for detecting failed tool releases
[2] I change the noise limits and/or disable the toolsetter based on the machine's XY position, as a "fix" for the above.
[3] the servos can stop on a dime, but the rest of the machine is limited by its strength and momentum.
[4] I really like the Mesa products, and really appreciate the work you folks have put into them
 

There are reasons why brushed DC motor powered machines have two sets of limit switches, one set does normal limiting while the other set is "extreme limits" that will cut all power to motors.
Brushless DC and steppers motors have no need for such measures as if the drive fails it usually causes the motors to lock and burn quietly, if all other safety measures fail.

Hello snowgoer540,

I had a quick question: would it be possible to also set or override the Material Thickness using magic comments in the G-code?

The idea would be to pass the material thickness directly from the CAM/post-processor, to avoid manual input and reduce the risk of forgetting to set it in the UI. This could be especially useful when running multiple materials with different thicknesses in sequence.

Regards

tommylight wrote:

Or on weak machines where any motor can do damage.  I had an accidental "hard stop homing" on my old wooden CNC.  The limit switch failed and the motors ripped the end off the gantry before I could stop it.
 

I should probably mention how it's set up.  You will have a spinbox for Slat Height in the Probing section, and a spinbox for Thickness in the Material section of the Parameters tab.  If you set BOTH the Slat Height AND the Material Thickness, then the probe start height will change based on the material thickness. 

If either Slat Height OR Material Thickness are 0, then it will default to Probe Height.  A high level recommendation I have (I have not tested this in practice, yet) would be to set Probe Height to 0.  When Probe Height is 0, the probe movement will begin at probe speed from the current Z position.  In most, if not all, cases while running a program, this would start a 5mm (0.197") below Z maximum height, as the g-code filter automagically adds these moves by default.  That means that if you forgot to set a material thickness, your probe would start from the highest point possible, and it would probably be obvious that you need to fix it, and it would be the "safest" option.  

 

Sorry, for some reason it wouldn't upload some of my pictures.

I found a Hypertherm PDF on grounding. My conclusion is that I need a grounding rod in the ground. I do not currently have one. I will start there. And I will go through my shielding grounding to make sure that is good.