Advanced Search

Hi Andrew,

I don’t have anything specifically for hal configs yet, but it is high on my to do list. Your inquiry has helped me to get off my butt and write up what I’ve been doing and experiencing. I have a knee mill with one micron scales, servo motors & drives configured in velocity mode and ball screws.
The ball screws are from Rockford ballscrew they have an adjustable design that is supposed to be able to adjust the backlash out. It kind of works. The problem is instead of backlash they have “wind-up” I guess technically its not backlash like “open space” but the wind-up causes problems very similar. Because adjusting the ball nuts takes a lot of time I put it off and that’s when things got really interesting. The wind-up became more and more, up to nearly +/- ten thousandths. I could measure it because I integrated the original hand wheel dials in my retro fit. The dials are an excellent reference for tuning, you can literally see the oscillations and overshoot. As you probably know because of the windup all of the direction changes in circular interpolations had oscillations which could be seen the halscope but also in the surface finishes but not really measurable. Going point to point was and still is spot on within a tenth. With so much easy windup in the ball nut the cutter would occasionally grab and take a really heavy bite (climb cutting) and pull the wok piece/table into the cutter. It was easy to hear and almost visually perceivable when it happened. When it happens it is so very fast, so fast that I believe it’s beyond the linear scale encoders ability to read and it misses counts and results in a position losses.

I’m pretty sure this is happening because when cutting a pocket that steps down in increments the pocket migrates. Since the grab usually happens in the same place on each level it migrates the same direction, it’s very repeatable. After a few pocket increments I would command the tool to go to program Zero and it go to where the control displays zero but it is NOT at work piece zero. When I back-off the cut parameters so there is no tool grabbing (really light cuts)there is no loss of position. My gut has been telling me this is most likely NOT a problem for large machines with very heavy tables and very little backlash and I’m not sure how much a dual loop feed back will help with the grab and missing counts situation with my machine. If the ballscrews were truly zero backlash there would be no problem, potentially no need for dual loop feedback. I’m going to try some things, hopefully I’ll get some time to do it this winter.
-Doug

Can you compare with PLANNER_TYPE = 0
can you share your testing g-code?

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.