Advanced Search

Yes, the error spike at the beginning and end of motion cannot be eliminated without jerk control.
 This is because without jerk control you have a step function in acceleration=force which is physically
impossible as that requires infinite motion control bandwidth.

Hi all.
This is currently working at dining-table levels, but will (hoepfully) become part of a Morbidelli Author 503 retrofit. I haven't found many examples of working mb2hal .hal and .ini files and had a bit of a time getting it all to work, so wanted to post results/a simple guide now that it does. The Morbidelli wants somewhere near 60 inputs/90 outputs and the budget is tight, hence going for the cheapest available:

Geroosaty UM72 board, model number on the board is N4D3E16. These were about £18 each.
Waveshare's USB to RS485 converter based on CH343G and SP485EEN chips, for about £15.
Linuxcnc version is 2.9.8.

I've attached .ini and .hal files. Note that modbus_io.ini is not a separate config file for lcnc but the config file for the mb2hal component. 

The board is 16I/16O, 24v, and has SlaveID settable by dip switches:
board 1 has A0 ON and A1-5 OFF for SlaveID 1,
board 2 has A0 OFF, A1 ON, A2-5 OFF for SlaveID 2.

I found some docs which suggest that the baud rate can be changed to 19200 but default is 9600. Wiring: A and B were correctly marked and wired A to A, B to B; GND was attached to the GND of the 24v psu.

I didn't have much success with modbus functions other than 03 or 06; other functions I could get to show up in hal configuration, but either not work or work in a way I couldn't use, hence the weighted_sum components. Notes there: weighted_sum doesn't seem to work with the 'names=' option, just numbered instances. Invoking 'weighted_sum' instances are referred to by 'wsum.0, wsum.1' etc. and when you add them to the servo thread, you add 'process_wsums'. Also when setting up the bits and their weights, it doesn't like the form 'wsum.01.bit.01.weight' but worked when 'wsum.1.bit.1.weight' was used.

I hope reading my config files helps someone else with this setup! Spent a whole day trying to get it to work with either one of two identical but ~15 year old rs485-usb adapters, eventually binned them and had the waveshare one working in a few minutes, once it arrived. Happy New Year all

Andy

yes exactly ... if all axis homed then ini.traj_planner_type == 1 else 0 ... its important for external drivers over buses maily... 

2nd day of testing at hardware is away... motion is way smoother and followinf error ar beginning at ending of movement is away too 

thanks

It happens there are several pdos in a syncmanager, it's ok.

I don't see anything obvious wrong. So it can be some details.
Here are some options.
Check output of syslog "sudo dmesg | tail -30". The EtherCAT master writes 
messages there especially things it doesn't like.

The PDOS might not be configurable. You then need to specify exactly
the order the pdoentries appear, with correct sizes, don't skip anything. You have your listing
in some disorder so that might be it. Take help from the output of "lcec_configgen --typedb=false"

 

Typically you would wire it (in hal) to joint.0.amp-fault-in
(a true on any joint.x.amp-fault-in  will cause LinuxCNC to halt motion)

Most of your concerns are not valid.

The final position after homing can set by HOME linuxcnc.org/docs/stable/html/config/ini-homing.html#_home so it does not need to finish at the end of the table.

Use G54 offsets to touch off using your microscope after homing. Most GUIs have touch off features to automate this and here you will correct any accuracy. (Machining should be done in G54 or similar coordinates). This lets you use multiple vices (G54, G55  etc)

I don't think your concerns about additional wear and tear are valid. Typically you only need to home the machine once per day
There are no wiring or parts required to implement this. Why don't you copy your config and give it a go. You might find you like it.

 

    Good morning, I am new to this community and joined in hopes you could help me step into the world of CNC’ing. Couple of years back I purchased this multi-cam CNC that had been sitting for a while. It had been used to machine deep pockets into Ovation guitar bodies. After cleaning out all the fiber material I found all the slide bearings in almost new condition. I took a bunch of picts and proceeded to completely disassemble the unit for restore. All the wiring too! I thought I would I’ll just look up what information I need to put it back together… bad plan! Not only can I not find how to wire these components I’m not even sure where to begin, what to keep and what to ditch.I will replace the spindle but would like to keep using the x,y,z motors. These are Allen-Bradley N-3412 B series brushless servo motors powered by Electro-Craft DDM-009 drives. All the rest I want to have new. I figure to use LinuxCNC on a Raspberry 5 with Unbuntu to control these x,y,z axis and (maybe) control the spindle (whatever that will be) separately. What add-on board and how to finally connect the motors escapes me.I have looked and looked but don’t know where to start. I need help.I would greatly appreciate any advise or direction. 

Hi Mbrandt,

I am using the Mesa 7i97T for 4 seperate axes with Heidenhain encoders and Tacho DC servo motors on my milling machine.
My servo amplifiers get the setpoint +- 10V and the Enable signal from the Mesa card. Very simple and straightforward. The inputs from the Heidenhain EXE ( I would assume, that your machine has the Heidenhain EXE card/units on board) are also easy to connect. The read-out of the positions worked immediately.
I bought the MESA card from EUSurplus in Portugal - the only source, where it was available in Europe, Highly recommended dealer.

Best regards

Hartwig

I got the ENA setup and working properly. Enabling the machine turns on the drives as expected. Now I just have to work on handling the ALM signal when there is a problem reported. What is the current way of handling this? I think I need to tie in fault-in from the motion module.

Hello again!
I finally received the drawings of the electrical, hydraulic and air circuits. Now I will count the exact number of I/Os. Then I will make a list with the exact signal of each I and O needs. It would be nice, if someone could correct me on my choice of mesa cards.

Here they are (lower resolution), maybe I can help someone with this:
 

Already replied on the other topic.

Hi,
I installed EasyProbe exactly following video and instructions.However, I can’t use the midpoint and distance probing functions because I keep getting an error related to M130.LinuxCNC shows “Unknown M code used: M130” when I press the X0 / Y0 / Z0 / R0 buttons or when an abort occurs.I already set the M130 file as executable, but the error still happens.Could you please clarify:
– where exactly the M130 file must be located macros, nc_files, or another folder?
– and whether M130 must be afile or a shell script?I’m using LinuxCNC 2.9.4.

7I76EU inputs are sinking inputs, that is, they detect a positive voltage
relative to field power ground. They will read "low" in hal until there are at
~60% of field voltage (~+14.4V at +24V field voltage)

If you use proximity switches, they should be PNP (sourcing) type.
NPN type switches would need a pullup (say 2.2K 1/2W) resistor to
+24V to work.

Hi Rod,
thanks a lot for your comments.
For me and my profile of usage, the homing is not usefull because of several reasons:
- I use a centering microscope or the touch-off by the miller to zero the axes in Axis
- My workpieces typically fit into a "space" of 50 x 50 x 10 mm. Homing would leed to a lot of additional movements and would create much more wear and tear on the gearboxes, leadscrews and dovetails.
- I would doubt, that my limit end switches have a repeatablility of +.-1 micron. So the home position would not be very precise.
- And finally the esthetic aspect: if my mill would sit at the end positions when it is not used, it would look odd to me
Best regards
Hartwig

der plotter ist cool

der unterschied ist, das im test gui nur gesagt wird das der pulsgenerator (FPGA->Stepdir) eine bestimmte frequesnz erzeugen soll, also die steps (velocity mode).

in linuxcnc hängt der pid-regler drin, der schaut wieviele steps schon erzeugt wurden und passt entsprechend die velocity/frequenz im step-generator an.

Bin leider auch kein mathematiker, aber ich denke
wenn LinuxCNC nun auf 0.01mm genau fahren will, der stepper aber nur 1/12 mm genau kann, dann spingt der PID regler als am ziel vorbei.