Advanced Search

我发现这个版本无法使用 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.

i found some really odd namings in the ui for the widgets, it is very confusing and appears to be unfinished or a the very least very poorly internally connected. i'm not sure where some of the parameters are coming from or if they were intended to be hard coded only in the var file or not. I don't think this is actually a finished project from the looks of it, at least not from the link you posted above. you may want to try contacting zmrdko.

from my scan through the ui, subroutines etc, things do not match up and widget names are duplicated as if copied and pasted but not correctly named so it's hard to follow the parsing flow correctly.

there is also no custom_config.yml setup instructions for the ui widgets to be stored in and saved and loaded on startup which means everytime you startup probe basic, those variables in the ui will be dumped and set to placeholder text (0.0000) which will be unsynchronized with the persistent var file data.

these are things that can be resolved in the upcoming release as i created a new var line edit widget that will not rely on subs to store and load variable from the var file.

some of the numbered parameters you listed above are linuxcnc params:

linuxcnc.org/docs/stable/html/gcode/over...:numbered-parameters

any params used in probe basic or any other add on would be between 3-5000 as these are user configurable parameters. anytime you see one 5001 or higher it will be a dedicated parameter used in linuxcnc.

I would say that this project is still a work in progress from my look into it.here is my mapping of everything, you could probably fix it and ask the developer for a pull request if you wanted, that would be the course i took,but as it stands i don't think you will be able to get it working as is.

 

 

I misunderstood your previous inquiry.
Right, you are satisfied with the performance of your existing system and would like to add a switch to monitor whether the cylinder support is extended before allowing the machine to start. If this statement is correct than you have two choices:
The switch will act as permissive, ie when switch is active the machine should not be able to start.
Or the switch will act as an interlock, ie anytime the switch is active the machine shuts down?

I work with a larger community makerspace and people missetting the z and gouging the spoilboard is the bane of our existence,

I would like to implement this:
1.  there's a wireless toolsetter you use as normal to set your top datum jobs.  This is the "User Offset" (UO).  I only mention this to make it clear that the tool offset test is a different thing.
2. a ToF rangefinger on the head.  NOT to try to distance the work, bed, or bit.  Rather, it's mounted above the spindle and if it is not running and senses hands in the area needed to undo the collet nut, it assumes the bit has been changed strobes a "safety touch off required" (STOR) signal that linuxcnc latches.  STOR is basically "tool offset is now unknown, don't run until the tool offset is checked"
3. The safety touch-off is a second toolsetter located in a fixed place on the machine, with a known fixed Z-height above the bed.  The STO cycle finds the z height of the bit tip and scans the loaded file for the lowest Z-coord, applies the current UO, and if it goes below the bed in machine coords, sets Z Safety Lock Out (ZSLO) which locks out the Run mode.  STO test never reorients the job, it only locks out run mode until the user corrects it
4.  Loading a new file, rerunning the wireless toolsetter for a new UO, manually entering a new UO, or running a new STO cycle triggers a reevaluation which could reset the ZSLO.  
5.  STOR is only set upon power-up or the ToF rangefinder detects that the bit  may have been changed.  False triggering the rangefinder and setting STOR is acceptable as it is just a small nuisance, but it should be impossible to interact the with collet nut without triggering STOR.  The corrective measures in #4 do not set STOR since the tool offset is already known.  It is not tested every time you press RUN.  
6.  STO can be initiated manually, or, pressing "RUN" will always trigger an  STO before running, which will either continue on into the RUN mode, or trigger ZSLO and enter the STOP state.

I know this will not protect against bit slippage.  I have wondered about how to do that for awhile, but can't see a solution other than conductive spoilboard.  Conductive spoilboard could actually work, it could still allow shallow excursions into it.  When the spoilboard is grounded by bit contact, the distance from the current Z and the lowest Z in the loaded file cannot be >2mm or we retract Z and stop.

Only problems there are you can't use conductive stock (bypass mode possible), but the main issue would be a cost-effective way to make spoilboard conductive enough.  Then again, if the spoilboard isn't getting consumed regularly, a high-effort way to make it conductive could still be practical.
 

Hello. I've build a setup with ASUS prime N100I-D D4
Turned off some CPU related features in BIOS and added
to linux kernel cmdline params
"isolcpus=2,3 acpi_irq_nobalance noirqbalance"

So Max Jitter(ns) for Base thread is 29725.

Any other optimizations which I've forget about?

Hi,

sorry this this probably a very basic problem but I couldn't find a solution myself: I can jog the machine out of the axis until the limit switch triggers. I have shared home/ limit switches and my understanding was that after homing the machine would know where it is and prevent jogging until the limit is triggered.

I suspect my Home / Home offset /  min limit is the likely cause but as I said I cant figure it out

Currently I tried 
HOME = 5.0
HOME_OFFSET = 0.000000
MIN_LIMIT = -1.0

I also tried 
HOME = 0
HOME_OFFSET = -0.800000
MIN_LIMIT = -1.0

but both still do not prevent me from jogging the axis until i get an limit error at which point I have to restart the machine and manually move the axis free.

Thanks!!

1. whatever you are doing to log all the 0's and 50's , don't, just had to scroll through over 70 pages of it, it is not fun and wastes a lot of very precious time
2. none of the two mentioned errors will not stop the LinuxCNC from running
3. Python error, as noted at the end of a very long error log, having to do with jog buttons as it seems
-
Try using Axis GUI, make the machine work properly by fixing latency issues and the "dolt not cleared" as this will disable the Mesa card completely.
Then try other GUI's.

Solving the realtime delay should solve this? Didn’t consider this as I thought Python did not ran in realtime

So you are saying that the latest stable version is not known to work? It worked great for me...

Shouldnt I try to update the my stable branch first?