Advanced Search

kcjengr.github.io/probe_basic/machine_config.html
in the docs

SSDs are overrated.

HDDs are good, plus you can find old HDDs in old computers, which usually work fine.

SSDs usually have to be purchased new.

They are mostly good for Windows because NTFS has fragmentation issues.

They do reduce boot time, but that is not really useful.

RAM is faster than any SSD, even "slow" DDR 866MHz is faster.

Make sure your RAM is dual-channel; you can get double speed with no drawback, why not?

If you just want to stop all axes when the cylinder support is extended then you can use “motion.enable” pin.

From doc, motion.enable:
If this pin is driven FALSE, motion stops, the machine is placed in the "machine off" state, and a message is displayed for the operator. For normal motion, drive this pin TRUE.

Practically: you need a limit switch wired to your hardware input. And you would need to add the following hal line to your existing hal file:

net cylndr.extnd   hm2.your-input  motion.enable
(Replace hm2.your-input with the correct address)

What the above hal code does: when hm2.your-input pin goes true the motion.enable pin will be true normal operation resume, when the cylinder is extended the switch opens and stop all axes motion. Assuming that the limit switch is normally open and your hardware input is sinking (positive logic). 

SSD will improve latency a bit, but adding more RAM would also help, 8GB is just fine, but i do not recall how much you already have.

I just ordered a SSD for this old computer. Now that I know it's working, I would like to speed it up
Will this also improve latency for linuxCNC or doesn't it matter, since everything is stored in RAM?

Thanks for the quick reply. On installation, I copied the "macros_metric_sim" folder into my "subroutines folder" from the "rack_atc_sim" folder, is this correct?

Manually clamping / unclamping works (so it seems to use the "clamping" and "unclamp" Gcode).

I attached my machine config (currently a bit messy as I switched from a custom Rack tool changer (which worked so far), to the probe basic one and I think I found one issue (which I fixed). For some reason, I had the following line included which broke something.

REMAP=M6   modalgroup=6  prolog=change_prolog   ngc=toolchange  epilog=change_epilog

Removing this at least lets me click "Store tool in Rack". However, it doesn't do anything except for setting the active tool to "No tool loaded". It doesn't move my spindle. Clicking "Ref Rack Data" (still don't know what it does) gives me the "Unknown M Code used: M13").


 

Does iocontrol.0.emc-enable-in go false when you request an Estop with your switch?

How is the input common on your isolated inputs connected?

Assuming this is a 7I95/7I96/7I96S, the isolated inputs on  these  cards
will work with input voltages from 4V to 36V
 

It would be better to ask this question in the qtvcp section.
Qtdragon doesn't use Glade. You won't need Qt Creator either.
To modify the .ui file, install Qt Designer.

Marek

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.