I just need to home with 3phase planner (because of my own code) and then after each joint is hommed I want to use the scurve 7phase stuff..

 It is just quick setup and forum is my external notepad ... 

Luca can I ask you about your ideas of optimalization of the code to avoiding the spikes? 

Which rabbits do you have in your hat btw?

Endian, you should use or2 gates, not and2, if for example only X is homing you still want planner 0
Also the mux2 values I think are reversed.

I just now tested on a virtual machine, QtDragon XYZ Inch simulation. I can select jog increments and click the jog buttons and it seems to move correctly. But my keyboard is jogging in continuous mode regardless what increments I select. Resulting in a random amount of movement each time I peck an arrow key.

My LinuxCNC version is 2.9.2, I didn't find quick where to see what QtDragon version I've got.

Small increments is working but not the larger ones, same as you described.

Sorry to bring this up again. Now upgraded to the latest release of Linuxcnc 2.9.8 as a fresh install. Changed to a new keyboard and the jogging issue with increments is still there.
Software buttons in qtdragon_hd work fine. Keyboard arrow keys for xyz yield random results for anything larger than 0.1mm increments.
Could anyone please try their keyboard to see if they get the same problem?
Thanks in advance

Hello, I picked up awhile back a 3D touch probe and I can't seem to wrap my head around Z zero.
 I have not installed it yet, installation and configuration I have no issues. I currently have a tool setter and touch plate.

 My question I can't see in my head is Z zero, when the touch probe detects a material surface Linuxcnc has no idea where that probe tip is in space so of course it Zero's Z. Now when you change to a bit and the toolsetter routine creates a zero offset for it the offset is to what?

 My thought was to use the tool setter to detect the toollength of the probe but a combination of multiple spring loaded buttons may throw off the actual tool length.

 Thoughts?
Thanks

Attaching what documentation I could find, though these refer to the boards having baud rate jumpers, which mine did not.  

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.