Advanced Search

another update

pgf wrote:

 Given that the length of the bit is variable, there is no single actual lower hardware limit. It depends on how far the bit protrudes from the collet. Given that, what's the use of the limit? When would it do me any good?

Adding an upper Z limit switch is usually pretty easy and makes it easy to use Linuxcnc as intended. eg Work in G54 offsets.
Normally, you would jog down so the tool touches the workpiece and set your g54 offset. 
Using work coordinates eg G54 was my biggest learning.

You have to remember you are dealing with cartesian coordinates.
You can home to any corner you wish. Homing to the lower left of the worktable means all x,y coordinates are in the positive quadrant.
Homing to another corner will mean at least one axis will count in the negative direction. Think of the graphs you drew at school

I did have a machine where the home switch was at max Y but I added a home offset to make the home position at min Y
Thinking about it after using it, I realized I could have homed it at the home switch position so the Y axis would count in the negative direction beecause once you zero G54 offsets at lower left on your workpiece, everything would count in a positive direction anyway.

tommylight wrote:

I have plenty, you are welcomed to use them, but i can not guarantee the quality! They do chew on everything in the shop though, seem pretty healthy by the looks and the speed they move through the shop. 

I had one but I bought a better mousetrap and the offending rodent was dispatched in under an hour!
Anybody want a used but battle proven mousetrap I no longer have a use for?

Just to be sure about this...where are the limit switches physically located in relation to the travels?

With the table all the way back and to the right?

[Sorry for the following Wall-O-Text, but I got on a roll ]

OP-
Incremental encoders have a resolution which can be expressed either as 'lines' or 'counts'.

In the case of a wheel with slots, each opening is considered a line.  For optical glass encoders, a line is one of the etched or printed black lines on the encoder disc.

If you have a 1000-line (or 1000-count) encoder, that means the disc has 1000 of these interruptions in the optical sensor/reader.

What causes things to get a little confusing is that the drive doesn't just sense one pulse for each line that passes the optical sensor.

There are two sensors in the read head, and one is slightly advanced from the other.  Both of these sensors send signals to the drive, and we call them the "A" and "B" pulses.  So that's two pulses per physical line on the encoder disc.

But it gets better... the drive can sense the rising edge of each electical pulse, as well as the falling edge.  For example, when a line goes past the A-sensor the drive sees a voltage change from 0 to 5v.  Then when the line gets all the way past the sensor the drive sees a transition from 5 to 0v.  Each transition - 0-5 and 5-0 - counts as a 'pulse' to the drive.

Same thing is happening on the B-sensor, and since the A-sensor is advanced a little bit from the B-sensor, the drive can count 4 pulses for each encoder line.  So we basically get a 4x improvement on encoder resolution for free.

Since your motor has a 1000-line encoder, the drive expects to count 4000 pulses per revolution.  This where the "1000/4000" jargon I dropped on you earlier comes from.

www.motioncontroltips.com/faq-what-do-x1...ncremental-encoders/

You can imagine what happens if the drive is programmed to expect 4000 pulses per rev, but the encoder is a 800-line (or some other non-matching value).  The drive thinks the motor is spinning at a different RPM than reality, and the motor magnetic poles don't line up with what the drive has calculated should be the case.  The drive won't turn on/off the coils at the right time, and the motor might turn but would make noise and not move to the correct position.  A significant mismatch would probably result in the drive erroring out.

That's why I suggested checking what value the drive was programmed.  It was unlikely there was a mismatch as most of (if not all) these cheap closed-loop steppers have 1000-line encoders so the drives are generally programmed for 4000 pulses, but it doesn't hurt to check while you're in the tuning software anyway.

You do NOT adjust the 4000-pulse encoder setting in the drive, regardless of the INPUT steps-per-rev setting in the drive (or in LCNC).  That encoder number is explicitly determined by the encoder on the motor.

Input steps per revolution on a programmable drive can be just about any arbirtary number.  While the motor has 200 physical steps (positions) due to it's construction, you can program the drive to move however far you want per input pulse (not encoder pulses).  If you program 1ppr input, then the motor will turn one full revolution for each pulse.  If you program the drive to 3157ppr, it will move 1/3157 of a rotation per input pulse.

Setting the drive to a higher input ppr than the encoder pulses means the drive is just guessing - the encoder resolution has to be higher than the input pulse setting for everything to work cleanly.  You can set the input higher than the encoder in the software, but there's no way the drive can accurately move the motor exactly where you want it because the drive has to guess where the motor is between the encoder pulses.

Older, non-programmable stepper drives were limited to either 200 input steps/rev for a 1.8 degree motor, or some multiple of that native 200 selectable via dip switches.  So when you see '4x', '8x', etc. that means you got to pick 200ppr, 800ppr, 1600ppr and so forth.

If after you take in to account the mechanical transmission (ball screw, belt ratio, etc.) the math didn't work out cleanly, you wind up with some strange number of input steps per machine unit (inches, mm, degrees).  Thats how you get from a drive set to 8x (1600ppr), through a 3:1 belt, and your units are in degrees (1/360)... so you have to tell LCNC to output 13.3333... steps per degree of spindle rotation.

LCNC can't output one third of a step, so whenever you have a non-whole number of steps per unit of measurement, there's a bit of "ish" involved with where the motor lands. LCNC doesn't lose track of where it is, but it can't move the motor exactly where you want.

However... if you program the drive with an input ppr that results in a whole number for each machine unit - degrees in your case - then LCNC can output a number of steps/pulses that can resolve to exactly one degree.  For your belt drive, that means 1200ppr at the drive input results in 10 steps per degree - a nice whole number which means LCNC can resolve to 0.1 degrees per step.  And 2400ppr gives you 0.05 degree per input step resolution.

Remember a few paragraphs ago when I mentioned keeping the input ppr lower than the encoder resolution?  Both 1200 and 2400ppr input values are lower than the 4000 pulse encoder, which means the drive would still have a chance of positioning the motor fairly accurately.

You machine isn't going to actually be 0.05 degree accurate due to variations in the belt, pulleys, friction, lost step here or there... but your INI file will certainly look neater.

Hope that helps.

I see you are missing the abort INI entry:
linuxcnc.org/docs/stable/html/gui/qtdrag...tml#_abort_detection
This is how the probing routines detect errors.
Please add it and the file it requires and try the probing again.

Hi,

I'm currently playing with TMC5160 on Linuxcnc in full SPI mode and am happy with the result. Just received a pcb to stack 6 of them on a Pi Hat: (well, on a Radxa zero 3E on the picture)

 

You only use 5 pins from the PI, so plenty left for other stuff. I also added the possibility to connect two 24V end switches directly on the TMC's. And a clock signal generator is on the pcb, so the TMC's share a 16MHz clock, which means better sync and faster SPI communication.

Enough jokes about mice!

I will copy the config and try QtDragon.

Maybe you should get away from those mice, you see from Tommy what they can do.
I don't know if it is better with a mouse, Qtdragon is designed to allow the use of fingers, even thick fingers.
You can always try. Make a copy of your current config and experiment with QtDragon.
Get the QtDragon setup from the linux examples (simulator examples) and mix in your ini and hal files.
If you are able to do that you won't destroy the current config and you get a chance to try QtDragon on your machine.

linuxcnc@linuxcnc:~/Desktop$ ncam --catalog=lathe

NativeCAM info:
   inifile = NA
  NCAM_DIR = /home/linuxcnc/nativecam
   SYS_DIR = /usr/share/linuxcnc/gladevcp/NativeCAM
   program = /usr/share/linuxcnc/gladevcp/NativeCAM/ncam.py


Using default lathe/menu.xml,  no lathe/menu-custom.xml found

Traceback (most recent call last):
  File "/usr/bin/ncam", line 4124, in get_selected_feature
    if self.actionDualView.get_active():
       ^^^^^^^^^^^^^^^^^^^
AttributeError: 'NCam' object has no attribute 'actionDualView'
/usr/bin/ncam:3660: DeprecationWarning: Gtk.ActionGroup.add_action is deprecated
  self.action_group.add_action(act)
/usr/bin/ncam:3658: DeprecationWarning: Gtk.ActionGroup.add_action_with_accel is deprecated
  self.action_group.add_action_with_accel(act, accel)
/usr/bin/ncam:3654: DeprecationWarning: Gtk.Action.set_icon_name is deprecated
  act.set_icon_name(stock_id)
/usr/bin/ncam:2803: DeprecationWarning: Gtk.UIManager.get_accel_group is deprecated
  self.accelGroup = self.uimanager.get_accel_group()
/usr/bin/ncam:3936: DeprecationWarning: Gtk.UIManager.get_action is deprecated
  self.actionSingleView = self.uimanager.get_action("/dummy/SingleView")
/usr/bin/ncam:2964: DeprecationWarning: Gtk.Action.create_menu_item is deprecated
  mi = _action.create_menu_item()

(ncam:1781): Gtk-CRITICAL **: 11:59:35.761: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
/usr/bin/ncam:2966: DeprecationWarning: Gtk.Action.create_icon is deprecated
  mi.set_image(_action.create_icon(menu_icon_size))
/usr/bin/ncam:2966: DeprecationWarning: Gtk.ImageMenuItem.set_image is deprecated
  mi.set_image(_action.create_icon(menu_icon_size))

(ncam:1781): Gtk-CRITICAL **: 11:59:35.762: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ncam:1781): Gtk-CRITICAL **: 11:59:35.762: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ncam:1781): Gtk-CRITICAL **: 11:59:35.763: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ncam:1781): Gtk-CRITICAL **: 11:59:35.763: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ncam:1781): Gtk-CRITICAL **: 11:59:35.763: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ncam:1781): Gtk-CRITICAL **: 11:59:35.763: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ncam:1781): Gtk-CRITICAL **: 11:59:35.766: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ncam:1781): Gtk-CRITICAL **: 11:59:35.766: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
/usr/bin/ncam:2809: DeprecationWarning: Gtk.UIManager.get_widget is deprecated
  self.main_toolbar = self.uimanager.get_widget("/ToolBar")
/usr/bin/ncam:5095: DeprecationWarning: Gtk.ToggleAction.get_active is deprecated
  if self.actionDualView.get_active():
/usr/bin/ncam:5641: DeprecationWarning: Gtk.Action.set_sensitive is deprecated
  self.actionCollapse.set_sensitive(self.selected_feature is not None)
/usr/bin/ncam:5662: DeprecationWarning: Gtk.Action.set_visible is deprecated
  self.actionChngGrp.set_visible(
DEBUG actionDualView.get_active
Previous work not saved as current work
Traceback (most recent call last):
  File "/usr/bin/ncam", line 5923, in <module>
    ncam = NCam()
           ^^^^^^
  File "/usr/bin/ncam", line 2827, in __init__
    self.load_currentWork()
  File "/usr/bin/ncam", line 5068, in load_currentWork
    self.action_new_project()
  File "/usr/bin/ncam", line 5086, in action_new_project
    xml = self.update_features(xml)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/bin/ncam", line 5524, in update_features
    recursive(xml_i, None)
  File "/usr/bin/ncam", line 5465, in recursive
    f_B = Feature(src=src_f)
          ^^^^^^^^^^^^^^^^^^
  File "/usr/bin/ncam", line 1784, in __init__
    self.from_src(src)
  File "/usr/bin/ncam", line 1848, in from_src
    src_config.read_string(str(f))
  File "/usr/lib/python3.11/configparser.py", line 739, in read_string
    self.read_file(sfile, source)
  File "/usr/lib/python3.11/configparser.py", line 734, in read_file
    self._read(f, source)
  File "/usr/lib/python3.11/configparser.py", line 1112, in _read
    raise DuplicateOptionError(sectname, optname,
configparser.DuplicateOptionError: While reading from '<string>' [line 90]: option 'header' in section 'PARAM_Z_RAP' already exists
 

embedded - incomplete view and no proper operation

standalone - it doesn't start

.....................................
ncam --catalog=mill    - ok
ncam --catalog=plasma   - ok
ncam --catalog=lathe   - it doesn't start, error in the next post
 

thank you!

I did find the 'encoder resolution' in the GUI and it was at 4000. Probably a dumb question but since we adjust the steps/rev to cleanly be divisible by 3 do we have to do something similar here? I again dont think i understand what encoder resolution means, what are the units of this? 

ill hold off on any pid tuning for now ill just update the error readings and reinstall it on the machine and start tuning it there.

Thank you all again for sanity checking and showing me the way!

Well reading the (correct, even) documentation hasn't helped.

Clearly, my expectations are wrong.  I have an axis that goes from 0 to 12.  I want to home at the "12" end.  It's a "bed moves" mill, so the motions are all backwards from the POV of the config, which is clearly expecting a "spindle moves" mill.  

Here's what I have.  The SEARCH and LATCH phases work fine, both searching negative.  But when the axis engages HOME_FINAL_VEL, it also heads in the negative direction to find HOME.  To be clear: HOME_SEARCH_VEL, HOME_LATCH_VEL, and HOME_FINAL_VEL are all moving the axis in the same, negative, direction.

With the INI as shown, it moves .5" before stopping.  (I've replaced "HOME=12" with "HOME=.5" for testing, simply so the axis doesn't move so far in the wrong direction.  I'm testing in the middle of the bed, simulating by activating the limit switch by hand.)

What do I need to do?


 

With a keyboard and poor-quality computer mouse, is QTDragon still better?

SIDE NOTE:
Why does pressing Ctrl+HOME launch the "Unhome all axes" dialog in AXIS?

The "Quick reference" pane says Ctrl+HOME is "Home all axes".