Advanced Search

Hello, I have a machine with X, Y, Z, B, C. How do I change Probe Basic from A-axis to B-axis?

[DISPLAY]
GEOMETRY = xyzab
...

[KINS]
JOINTS = 5
KINEMATICS = trivkins coordinates=XYZAC
...

[TRAJ]
COORDINATES = XYZAC
...

If I change three "A"s to three "B," only the X, Y, and Z axes are displayed in Probe Basic. I also adjusted the range [AXIS_X] to [AXIS_C].
Can someone help me?

@ Philip Lydin

You may have already done this, but you need to setup the EL5151 itself.  If you bought the terminal used, then I would do a factory reset to clear whatever someone did before you and then set it up.  Like Dominik Braun (DB1981) said years ago, you never know what someone has done before you.

If you don’t have Twincat, then you can do it from the command line (CoE).  Make sure to put the correct terminal number for the -p.  I have -p1 below as that would put it right behind the EK1100.  After the command, wait a few seconds, then power cycle the Beckhoff hardware.  (there are 2 hyphens before type)

sudo ethercat download -p1 0x1011 0x01 0x64616F6C --type uint32

The above will put it in quadrature.  If you want “counter mode”, then do the following command.  Don’t forget to wait and power cycle again after the new command.

sudo ethercat download -p1 0x8000 0x03 --type bool 1

If it’s already in counter mode with C reset, then you should be able to find out before doing the above commands with
sudo ethercat upload -p1 0x8000 0x01 - -type bool
If it’s in counter mode with C reset, then you should get something like  
0x01 1

Just don’t forget to put the correct terminal location for the -p as you don’t want to “brick” one of your other terminals.  Twincat is totally safe to do anything with the terminals, but you can permanently brick one doing CoE.  Even though Twincat is free, I still do CoE most of the time.


Like Hakan stated, Beckhoff’s manuals have everything, just a matter of finding the answer.


Hope it helps,
Robert

The file attached is a dirty patch to test only with qt_dragon interface.
The DISPLAY test function is disabled to allow NativeCAM to run.

If you would try NativeCAM with qt_dragon, follow the installation procedure (search in previous messages)
Replace the ncam.py file with the attached and add the line in green in the .ini file:

# required NativeCAM item:
EMBED_TAB_NAME = NativeCAM
EMBED_TAB_LOCATION = tabWidget_utilities
EMBED_TAB_COMMAND = gladevcp -x {XID} -U --catalog=mill /usr/share/linuxcnc/gladevcp/NativeCAM/ncam.ui

It will run in a strange way:
LinuxCNC will start with the NativeCAM error. Click OK
NativeCAM will start (not embedded)
LinuxCNC screen shows up.

The NativeCAM tab is empty and useless, but to use NativeCAM use ALT-TAB keys to bring its window up.
After sending the program to LinuxCNC, use ALT-TAB keys to bring  LinuxCNC up.

It's a terrible way to use it, but for now it at least  works.

Regards
Giovanni





 

Another way is to take a feedrate say 200 mm/min and divide that by 60 for seconds and 1000 for servo thread speed and you get 3.3 micrometers between position updates. 500 Hz servo thread gives 6.6 micrometers between position updates. No buffering, all real time.
I guess there are situations where this can make a difference, but normally not I would say.

With Mesa hardware (and most external hardware step/dir interfaces
or even EtherCAT drives), the velocity (step rate in this case) is updated
every servo thread.

This means that there is a constant velocity between updates. This constant
velocity means that that you will  have a small error (chord error) between a
desired curved path and the actual (linear interpolated) path.

This error is usually insignificant for most CNC machines at a 1 or 2 ms
servo thread period and typical CNC machine acceleration values.

For machines that are precise and fast (say with linear motors) you would likely
need  a faster than 1 KHz servo thread (or parabolic or cubic interpolation)

If you want to calculate the chord error here are some equations (at least for circles)

Chord error polygon vs circle =
R (1-cos(180/N))

R = radius
N = sides

R = Minimum Radius= V^2/A
N  = Sides = T_Circle/T_Sample

(a minimum radius circle at full speed is the worst case)

Using an example of 1 IPS (~25 mm/s) cutting speed and 40 IPS/S
acceleration (~ 1000 mm/s/s) and 2 ms servo thread,  the chord
error is about 0.00002" or 0.5 u.

If you increase the servo thread much longer you will start to have
issues on acceleration due to jumps between velocity steps, which
will limit your maximum acceleration setting.





 

Hello, I've finally found the error.
The problem is caused by importing entries from the "pb_required_ini_settings.ini" file.
This is the file:

[DISPLAY]
DISPLAY = probe_basic
OPEN_FILE = ~/linuxcnc/nc_files/pb_examples/blank.ngc
CONFIG_FILE = custom_config.yml
MAX_FEED_OVERRIDE = 2.000000            # Recommended Setting for Probe Basic
MAX_SPINDLE_OVERRIDE = 2.000000         # Recommended Setting for Probe Basic
MIN_SPINDLE_OVERRIDE = 0.500000         # Recommended Setting for Probe Basic
INCREMENTS = JOG .01in .001in .0001in   # REQUIRED Setting for Probe Basic
USER_TABS_PATH = user_tabs/             # REQUIRED Setting for Probe Basic
USER_BUTTONS_PATH = user_buttons/       # REQUIRED Setting for Probe Basic

[RS274NGC]
RS274NGC_STARTUP_CODE = F10 S300 G20 G17 G40 G49 G54 G64 P0.001 G80 G90 G91.1 G92.1 G94 G97 G98
PARAMETER_FILE = probe_basic.var
OWORD_NARGS = 1
NO_DOWNCASE_OWORD = 1
SUBROUTINE_PATH = subroutines

[HAL]
POSTGUI_HALFILE = probe_basic_postgui.hal
TWOPASS = on

And here's the error: USER_TABS_PATH = user_tabs/ # REQUIRED Setting for Probe Basic
There must be no comments after USER_TABS_PATH = user_tabs/, no "#" because that causes the error!!!

It should be possible if there is only one index
rather than periodic index marks

I've tried to run NativeCAM with qtdragon after a couple of changes:

# required NativeCAM item:
EMBED_TAB_NAME = NativeCAM
EMBED_TAB_LOCATION = tabWidget_utilities
EMBED_TAB_COMMAND = gladevcp -x {XID} -U --catalog=mill /usr/share/linuxcnc/gladevcp/NativeCAM/ncam.ui

And I copied an existing folder in qt_dragon config folder.

The NativeCam tab (empty) is shown, but NativeCAM wont'run cause it declares a DISPLAY problem.
I'll try to trick NativeCAM to avoid the display check, to see if it will run.

Regards
Giovanni

Hi!
Is it possible to home a machine only using the scales and no other limit switches? Have found a bunch of posts regarding this, but none gave me enough clarity. In one i think Andypugh did some testing/developing to get this to work?

/Hampus 

You will most probably get stuttering if you do not also set the P value to 500 for each joint/axis in the ini file.
Those two are strictly related for normal stepper systems, for 1 million servo period the P value is 1000, for 2 million servo period the P value is 500, for half million servo period the P value is 2000, and so on.
And i am pretty sure Mesa controllers do not use buffers for the motion control in the normal sense of "mach3" boards, might use for IO, but i never checked, after over 10 years of using Mesa boards (probably over 80 by now) and never ever having a single issue with them, and most are on industrial machines in use 10 hours a day every day (never turn off, though), and having tailor made firmware to my needs, and having the best support on Earth, i absolutely stopped worrying about it.

I meant to add:

But I'm more than happy with your answer!

Okay. I wasn't sure whether it could cause stuttering of some sort, if the commands to the Mesa weren't sent in time.

My naive mental image is that the Mesa service routine is called from the servo thread, and it sends multiple commands like "Step X +25 times and Y +10 times" during each call. And I assume the Mesa maintains a queue of such commands, and the servo thread needs to run often enough for that queue to never become empty prematurely.

So the answer might involve knowing how big a buffer the Mesa has for that queue, and whether the minimum execution time for a bunch of very quick commands in that queue is shorter than the servo period.

I do not think you have to worry about it, it just updates everything 500 times per second instead of the usual 1000 times per second. Probably changes nothing in the step generation part as it's done on the Mesa, but might raise the time to halt the machine from 1ms theoretically (practically 2-3ms) to 2ms theoretically (guessing 4 to 6ms), and since those are still way to short time intervals, i do not think there is a situation where one would save the machine and the other would break it.
Either way reaction time of normal mortals is in the half second to a full second range, minus the Formula 1 drivers, those must be gifted with some fast reflexes, otherwise the Formula 1 would be a race to who crashes last, not 2 hours of extreme stress, be if physical or mental.

If you installed linuxcnc as RIP,  before running qtpyvcp execute the following command at the prompt:
source ~/your rip path/linuxcnc/scripts/rip-environment 
Note you don't need to run linuxcnc just source its environment this allows qtpyvcp to find what it needs  to run

I didn't fully understand it, but I've already tested your update, everything works fine.