Advanced Search

Good evening, I am assembling a CNC electronics with a mesa 7i96 board and should wire three NPN/NC inductive sensors (LJ8A3-2-Z/AX) as homing sensors and six NC mechanical microswitches as limit sensors. Could anyone tell me how to wire the sensors to the board and the 24v PSU?

I attach photos of the sensors.

the quick gowin install way without login

just opened the software and the manual tells you nothing about any of the features i was curious to see how bad it was going to be and now i know god help me

I asked the same question, never got an answer.

what i said before was phrased as a question because i am in territory i know little about but thanks for the detailed answer to help me understand better.

i did download the software last night and had a look at the manual (PDF) and it sounds like the software is about as good as the manual

as for the lost steps i have not seen anything that shows that has happened if it is it would have to be pretty small and not obvious by eye. the only time the drive alarmed was in a stall from cutters loading up before i added the mist.At one point i even had a glass scale and DRO hooked up to see how accurate the belts were and did not see anything but that was with no loads involved.

i don't think i have any programs that are simple mostly 3D milling tool paths. I can probably do some testing this coming weekend. Anything during the week is pretty hit and miss for me since i work the night shift.

all the code i do is in fusion 360 if that helps any? i can't remember if i had smoothing in use or not that could be something to test i guess.

Are the motor tachometers connected to the drives?
This is necessary for velocity mode drives to work properly.

besriworld wrote:

Good job!
 

Thank you!

Feels like I have been working on this thing forever. It felt a bit cumbersome to start tearing stuff apart again however the noise from the straight cut gears in the gearbox combined with low sustainable max spindle RPM really made this is a necessity as making parts with a spindle that only did 1500 rpm was way too slow (anything above 1500 made the gearbox sound like it was going into orbit).

I've looked at several completely new BT40 spindles on AliExpress but the listings often have very little technical information about the spindles and the sellers so far haven't been able to answer many of my questions so for now the spindle that came with the machine will have to do.

The configuration and HAL changes ended up taking over a day to figure out but in the end I managed to get spindle soft ramp up and ramp down in place along with encoder based RPM and actual spindle load displayed in Probe Basic.

I've attached my config files for Probe Basic in this post (note that the custom_tool_change.ngc file has to go in the subroutines folder). In this post I'll highlight the areas which were hardest to figure out. Hopefully Google picks them up this post so that other people searching for the same things find this post.



Here is current wiring schematics for reference:



I started with modifying my AXIS configuration using Pncconf. It has been virtually fool proof for generating configuration changes before but the values it generated when selecting a servo spindle in step/dir mode were for some reason not really spot on and it took me a while to figure what was going on as I was getting error about MAXVEL being too high right out of the box.

Currently I'm using the following values in the INI file for the spindle and the encoder:

The new spindle servo has a maximum RPM of 6000 rpm but I've set the limit at 4500 until I have replaced the spindle bearings.

The acceleration values are set very low to ensure a smooth ramp up/down as the servo motor has a lot of torque and makes a very violent starts otherwise.

I carefully matched the polarity for the differential encoder signals from the servo drive to the Mesa 7i96S board but for some reason I still hade to invert the encoder scale otherwise it was reading rotation in the wrong direction. It should also be noted that if you have for example a 1000 pulses per revolution (ppr) quadrature encoder the ENCODER_SCALE value set in the INI file needs to multiplied by four.

The 2kw Delta B3 servo drive for the spindle servo came with a default setting of 2500 ppr setting but I reconfigured it to 1250 ppr instead as 10 000 pulses per revolution felt a bit overkill.

I left the PID settings completely stock but as I'm using a close loop servo I'm not sure that PID should even be enabled as the drive handles that and even triggers a fault if there is too much deviation between the commanded position and the actual position.


When it came to the HAL file I had previously picked up on the fact that the stepgen on the Mesa board used to control the spindle should be enabled by machine-is-on and not spindle-enable as otherwise it would cause very abrupt stops of the spindle when using a servo.

Pncconf correctly generated the following line in my case:

However I was still getting very abrupt spindle stops which I tracked down to the following line in the HAL file:

That line controls the enable signal sent to the servo drive, without it the servo drive immediately stops.

I wanted the servo drive to ramp down slowly when stopped and then disable the drive so that I can rotate the spindle by hand when changing tools etc. I the end I solved this by using the great example posted by pippin88 in this thread (forum.linuxcnc.org/10-advanced-configura...ep-dir-servo-spindle).

With these values set the spindle enable signal remains active for an additional 3 seconds when the spindle stop signal is given which allows the spindle to ramp down softly according to the values set in the INI file.

When I had the spindle working properly with both ramp up and down I turned my attention to the user interface of Probe Basic.
 
In order to get the actual spindle RPM from the encoder to work the following line had to be added to the post gui file, in my case the custom.hal.


Getting the spindle load bar to work took only the following 3 lines.

The really magic part in those lines is the scalemax parameter which I would never have guessed existed or figured out how it worked if it wasn't for a few excellent posts from PCW on this forum.

As far as I have understood it the analog inputs on the 7i84 board by default scale from 0 to 36.3v. By changing the scale to go from 0 to 453.75 the max 8 volts which the servo drive analog output gives is translated to 100. This makes the spindle load bar in Probe Basic go from 0% to 100% as the voltage to the analog input varies from 0 to 8 volts.

I know that it would probably be better to have the spindle load bar in Probe Basic go from 0% to something like 150% or 200% to allow for higher peak loads to be displayed but I put that on the todo list for another day

A stepgen is not appropriate for driving an HBridge

The 7i97t_5abobd.bin firmware includes a PWM generator
with its pins brought out on DB25 pins 1 and 14 (HDR26 pins 1 and 2)

If you have a working 7I97t analog configuration, (with analog Z axis setup)
to adapt to your Hbridge, you would basically just change the Z axis PWMgen
number to 7 for the external P1 pwmgen, disable offset mode, disable dither,
and set the PWM output type  to 2 for up/down PWM



 

Thank you for sharing your insights, RDA. I've read about the certification process but have never actually gone through it myself. It doesn't make sense to certify a driver for just one machine, but in the future, if a design proves successful and gains popularity, certification could potentially be beneficial.

Regarding the candidate power modules, designing a driver for a discrete IGBT can be a challenging task. In the past, I've encountered issues with parasitic capacitance from a similar module attached above, which led to the destruction of a Siemens servo driver that I was working on. The integrated solution provided by these power modules really simplifies the design process in my opinion. However, it's worth noting that including rectification diodes in an integrated solution may be redundant for a modular array used in robot control, as the drivers in such an arrangement typically only contain the inverter stage and not the rectification stage.

The Onsemi NFVA25012NP2T is a good option to consider for designing a prototype.

on the action button did you set both properties 'joint_number' and 'axis_letter'?

2.9.2 may not have the ethercat repositories installed. You may need to do this next
forum.linuxcnc.org/ethercat/53785-instal...thercat-repositories
 

machinedude wrote:

i was wondering if the fact that the Y axis has a lot more power than the X axis that would cause the feedback loop to work harder on the X axis and lag behind the Y axis? that would explain why it shows up on cuts when the X and Y are moving together.

adjusting the alarm set point might show this like you suggested. i just have to figure out how to make that adjustment i'm guessing that is done in the drive with communication cable they send with the kits.

 

'cause the feedback loop to work harder...' is not a meaningful statement.

Your X axis has one motor, and that motor only has to move the head.
Your Y axis has two motors, but each motor has to move half the head weight/inertia plus half the gantry.

There may be a significant difference between X and Y power/torque requirements, but that's probably due to bent or misaligned components and not a massive difference between X and Y inertia-per-motor.

Having said that, if a stepper motor-driven axis has more friction (or load) than the motor can handle, it doesn't 'lag behind'.  It will lose steps.  It may lose a couple steps every so often, or a bunch of steps and stall completely.

But it doesn't just run slower due to increased load.  Your axis motors are not a cordless drill that slows down when you stick a big bit in and overload the motor.

Yes, you need to install the tuning software, connect to the drive (drive powered on), and adjust the alarm setpoint value.  Be prepared for a horrible experience as the software is unintuitive and not well translated.

Do you have clear photos of the problem - i.e. surface finish - and a sample of the gcode used to cut when the issue appears?

Yes, the VFD is done through PWM. You kindly helped me many years ago setting this up. The Chinese BOB PWW and GND go to the VFD (Bosch) on GND and A1. I hav ethe 24V fromt the VFD also running through the relay on the 2 BOB's that I am using. I am using two as I need more than 5 inputs. I was hoping to use Mesa but stock is a massive issue. So my HAL was written using Stepconf and I put in there the max speed of 1420 at a full 10v. I assume Linuxcnc will think it is 1420 but the VFD will be running the motor at double that which I assume is OK as the encoder is on the spindle and not motor

Before homing you are jogging "joints" (0 , 1, 2,...)
After homing you are jogging axes (x, y, z, ....) , which run through the kinematics module, to calculate joint positions.
For a cartesian setup this distinction might seem pointless, but it save ambiguity in a lot of parts of the code.

Your jogging setup might be more convoluted than necessary.
If you _must_ use GUI buttons for jogging (hardware buttons are more reliable) then I would suggest using HAL buttons (ie, GUI elements that toggle a HAL pin) then wiring those HAL pins to the HAL jog inputs that operate independently of the GUI code.
The absolute most reliable way to jog is using MPGs that send counts to the "motion" module jog-counts pins. That is realtime all the way.
But if you want increment/continuous jogging from a button then you can use the "halui" pins.


The reason that I dislike keyboard jogging (which you are emulating, in some ways) is that it is possible for the GUI to miss the "key-up" event, and then the axis doesn't stop when you release the key.

Anyway, if using the halui inputs the answer to your original question is to wire the input to both joint and axis.

pseudo-code (I haven't checked what the actual GUI putput pin would be called)