Advanced Search

I found another problem with the MacroTab Widget related to the recent checkbox element improvement.

The checkbox element is not taken into account when numbering variables. All elements below the checkbox are shifted. #4 has value #5 etc. Two checkbox elements will shift everything below by 2, as in the screenshot.

Yes, the touch probe should be fine as long as it can be wired this way.

Note that many touch probes have a contact closure to ground, so be careful...
 

It seems the machine originally homed this way, but yes, you need to
guarantee the you are 2 index marks away from the end stop before
starting homing.

I believe there's no way to avoid using a home sensor. Because if the machine is left at the last index on the encoder line, when searching for the next index marker, it might hit the limit switch. But when you have a home sensor, it's much easier—you only need to check the first, closest index marker.

Thanks. Yes mine are of the PNP type. And same goes then for the input of the Touch sensor? This is not a PNP. This acts more like a mechanical switch.

That looks basically OK

If you have PNP type sensors, you do not need any additional interface components
that is the sensor output goes directly to the 7I76EU input.

7I76XX inputs are quite rugged, they need no additional protection.

 

Also, gears could wear differently in one direction depending on friction and how level your machine is.

(e.g. moving a heavy z axis will cause more wear in one direction than the other, and the uneven wear might mess with stuff.)

Belts do wear and stretch.

Make sure you grease ballscrews, bearings, etc. so they don't wear down over time, which will mess with accuracy.

Grease also makes the machine move more smoothly.

Hi All,I’d like your input on my planned setup.
As I mentioned in my previous post, the latency on my new machine was so high that I had to switch from the parallel port to a Mesa card. Earlier this week, I received a Mesa 7i76EU board. It looks awesome—if a bit overwhelming at first glance!My plan:

• Motors:
  I’m using 3x Longs DM542A stepper drivers, which I plan to connect to Stepper 0/1/2 outputs on the Mesa board, using what I believe is called a “single-ended” wiring configuration. My plan is to connect +5V to the ENA+, DIR+, and STEP+ on each driver, and wire the ENA (5V), DIR-, and STEP- of each driver directly to the corresponding outputs on the Mesa card.
• Spindle:
  I have a Huanyang VFD 1.5KW for spindle control. For now, I’ll keep my Modbus-over-USB setup, which seems to work well enough. I’ve read that getting Modbus running directly on the Mesa board requires a bit more advanced configuration, so I’ll save that for later.
• Homing Sensors (Capacitive, 3x):
  My plan is to connect the +24V supply to the positive (brown) wire, and field ground to the negative (blue) wire of each sensor. I intend to connect the sensor output (black) wires to Input 1, 2, and 3 on the Mesa card.

Questions:

1. Current-limiting resistor for home sensors:
   For the capacitive homing sensors, do I need to add a resistor between the output pin of the sensor and the Mesa input to protect against overcurrent? In the past, I’ve blown a few sensors and started using resistors to protect them, but those were cheap sensors—the Mesa card isn’t!
2. 2-wire touch probe:
   For my two-wire touch-off probe, I plan to connect one side to +24V field power and the signal wire to Input 4. Here too, should I add a resistor to avoid potential shorts or overcurrent situations?

Bonus questions:

• Any recommendations for best practices when wiring sensors and stepper drivers to the Mesa 7i76EU?
• Are there things I should definitely avoid to protect my Mesa card or improve reliability?
• For those who have set up Modbus on the Mesa board, how steep is the learning curve compared to using Modbus over USB?

Thanks for your advice and experiences!

The code (at least the code in your first post), works fine on 2.10.008.064.  I realize you are on some version of 2.9, just was easy for me to test on that. 

Can you state the specific version of 2.9 you are on (like above, as taken from the window title with QtPlasmaC open)?

Back when, there was a commit that temporarily broke feed reductions, but it was fixed. I honestly can’t remember if it was in 2.9 or master or both, but perhaps you have an older version that has the bug.

the best way to do this is to use the provided usertab, this way your edits remain with your config folder and do not get overwritten during updates (which a couple big ones are getting ready to drop). what you definitely do not want to do is edit the main probe basic because then you become the developer for any and all future updates which is not ideal for an end user.

to edit a user tab, open a terminal, type in:
editvcp

a dialog will pop up, in the dialog, find your machine config directory, typically it will be
/home/(your_pc_name)/linuxcnc/configs/(whatever_you_named_your_machine)/user_tabs/template_main/template_main.ui

in the file type drop down at the bottom of the dialog, make sure the type is set to VCP UI Files (*.ui)

this will show you the file :

template_main.ui

select it and click the open button.

Here you can add and edit it as you desire. when done, click save.

check your ini file and make sure that user tabs path is active under the display section:

[DISPLAY]
USER_TABS_PATH = user_tabs/

this activates the user tab and loads on probe basic start up.

enjoy!

If it was working and then changed I would expect that's more likely
to be a mechanical issue (loose coupling etc).

Two PCs were used in those machines.
NEC 9801UF / NEC 9801UV11
Thank you

Realistically speaking, the chances of someone else here having replaced the exact same computer is not high.

Could you post pics?

Belts and gearboxes do introduce backlash.

No encoder is exactly precise.