Advanced Search

Hello,I am responding to your answer because I have a problem with my E-stop. The E-stop on my Axis interface always remains on Off“net estop-out <= [HMOT](CARD0).inm.00.input-04”“net estop-out => iocontrol.0.emc-enable-in”. Whether my emergency stop button is pressed or not, my limit switches work very well. I have a 12V power supply for the whole system. Is a 24V power supply required? Thank you

Hello,
I am responding to your answer because I have a problem with my E-stop. The E-stop on my Axis interface always remains on Off
“net estop-out <= [HMOT](CARD0).inm.00.input-04”
“net estop-out => iocontrol.0.emc-enable-in”. Whether my emergency stop button is pressed or not, my limit switches work very well. I have a 12V power supply for the whole system. Is a 24V power supply required?

Thank you

 

lol...that will not be in my todo list..lol that is an external offering. you could spend a couple hours and get it working. it is just a matter of editing the surface map ui file, subroutine update file, custom_config.yml, and getting all the widgets and what not in synch with expectation, once that is done it should work as expected. its a fairly simple setup regarding what is in probe basic. it is all usertab based so you do not need a dev install to perform the edits. everything is externally accessible via the existing qtdesigner stock installation (from terminal run: editvcp probe_basic, then select open and point at the surface map usertab directory and find the surface map ui file), a decent text editor such as vscode or sublime etc for the subroutines and yaml file updates. I have not looked at how it connected to the graphical portion, but i would imagine once the names all are correct it should work great. if you plan on using it you would have a much better grasp on how it is used than me as i have never used it before and haven't mentally imagined using it so the process flow is lost on me.

For the PID settings for a hardware stepgen, P should normally be
1/Servo-thread-period so 1000 for a 1 ms servo thread period,
and FF1 should be 1.000.

The physical meaning of these setting is this:

P=1/Servo-thread-period means correct any detected position
error by the next servo thread invocation.

FF1= 1.000 means set the base stepgen velocity to LinuxCNCs commanded
velocity (to center the operating point of the PID loop on the current velocity) 
This means the P term has little to do besides correcting for minor time base
differences between LinuxCNC and the hardware.

Correct as interlock
If the cylinder is not retracted, the switch should stop all axles.
The axle needs about 2 seconds from the activation of the cylinder until it reaches the position of the cylinder!

Thanks for taking the time to have a look, and for confirming my suspicion that the surfacemap code might not be complete.

Is there any prospect of an official probe_basic surface grid probing and z-compensation tab? Perhaps using scottalford75's z-compensation code via external offsets:

github.com/scottalford75/LinuxCNC-3D-Pri.../master/compensation

(I think this feature may already be included in QTDragon, although with compensation via g-code ripper rather than external offsets).

Sorry for possibly adding to your already no doubt long to-do list!

Probe Basic is another project separate from LinuxCNC and it is developed on Debian Linux, so this might have missing dependencies for running it.
Use the official ISO for Probe Basic.

Thank you very much.
I will test this.

As far as I remember, there also were PID settings, either in
the pncconfig GUI or the config file itself.
Only P was set, which seems odd.

Are these settings even valid or doing something in
an encoderless setup?


thx
AS

我发现这个版本无法使用 Probe Basic界面， 是桌面环境引起的吗？

There have been no motion unit changes AFAIK between 2.8 and 2.9

A base period is not needed with hardware stepgens/encoder counters
(nor is it very useful with SPI or Ethernet connections)

The DPLL is a Digital Phase Locked Loop that re-times critical sampling times
(like sampling the current hardware stepgen position) This can reduce
the sample time uncertainty from 100s of usec to 100s of ns

Typical setup for Mesa stepgens is like:

# latch 100 usec before nominal read time:
setp hm2_[HOSTMOT2](BOARD).0.dpll.01.timer-us -100
setp hm2_[HOSTMOT2](BOARD).0.stepgen.timer-number 1


 

the latest stable version DOES work, but it is not working for you currently. what i am saying is i have no idea why you are getting that error and i cannot reproduce it here, so without knowing where or why that error is happening for you specifically and not here or being complained about elsewhere, the next logical step would be to update and make sure its not something wrong with your install or a change made that you may not remember making or be aware had effect that was made without your knowledge.

Before i spend any time troubleshooting with such little data on the problem, it would be prudent to know for certain that it's in probe basic/qtpyvcp and not an issue elsewhere.

I would also test the probe basic sim to see if the issue is there as well, if it is then it is probably an internal error issue and not a configuration issue. from there we can figure next steps. but identifying where the issue stems from is in my opinion the first step, so i would test in the sim and see if you can reproduce the error there. if not, then its a configuration change, maybe a stray typo from your editing? if you can reproduce in the sim, then i would say the next step is removing and reinstalling the stable branch and testing or testing, or testing the develop version. the develop version has file changes for the work coordinate system table and the dro's which may be a resolution. it also has a fix for running on linuxcnc version 2.10. i'm not sure what version you are running on, but if it is 2.10 it NEEDS the develop version.

tommylight wrote:

Keyboard jogging issue
www.forum.linuxcnc.org/38-general-linuxc...elocity-fluctuations
 

Grundgütiger. Lol; thx!

Maybe I should borrow $CHILD2's gaming keyboard and set the polling rate 
to 20kHz. I bet that the movement then cannot be stopped in time, hehe.

PCW post=332736 userid=481[...]  
The overshoot is likely a tuning issue, I would use the standard velocity mode/PID stepgen control
(use a pncconf created configuration for an example) Also make sure to use the DPLL for stepgen
configurations (use pncconf again as an example here)

I created the config file with pncconf and left the

The units all seem to have changed from 2.8 to 2.9. Instead of periods/time we now have rates/frequency.  
I have 20+ years experience with running everything through the parallel port but 0 with Mesa cards.  

I also noticed that the former "BASE_PERIOD" (forgot what the name is now and I currently do not have
access to the new config; forgot them in the workshop) is not in the ini-file anymore.  
Not sure if this value can be changed at all. The Mesa docs are more than sparse, imho.

I must admit that I don't know exactly understand what you mean.  
Is there also an "extraordinary velocity mode"? And what is DPLL?


thx
AS
 

you need the subroutines from the rack atc sim, they are specific to rack atc, the subroutines in the standard probe basic file are default for carousel type. copy over the complete subroutine folder from rack atc config sim folder to your machine config folder. should work then.

Sorry, I forget to mention I'd started working on this, only saw you'd self-assigned the issue once I'd nearly finished!
But I see you've seen my pull request now, just linking it here for anyone else since I'll carry on discussion there.
github.com/LinuxCNC/linuxcnc/pull/3534

The test above doesn't show the probe bouncing, it just shows that motion.motion-type remains 5 (Probing), which is what I initially wanted to test.

In hindsight I should've just looked at control.c first, because the logic in there fully explains why the probe bouncing during probe move deceleration causes the issue.

Currently, after the probe is first triggered from a probe move, it doesn't matter what the motion type is, because it's either the first and only valid trigger during a probing move, or a trigger during a non-probe coordinated move.

So the simplest fix to just give an accurate error message which checks the motion type to determine the error message (which is where having confirmed that the motion.motion-type remains as probing for the entire probe move is ideal).

We need more info about the machine, size on all axis, gear ratio, final drive, where are the switches mounted and what type, etc.
Is the scaling correct?
etc etc.