Advanced Search

I did a quick test on my non-rt installation running 'cmake/nc_files/fillet/square_100x100_P5.ngc'.
1. it seems that inital deceleration and final acceleration along the fillet do not respect max_acceleration settings (50 for x in my case)
2. there seem to be acceleration spikes while traversing the fillet

Below is the captured accelerations for X and Y for the first corner of the rectangle:

 

I know they are 6-wire, but perhaps they are 8-wire internally.

They always are 8 wire inside, they all have 4 windings inside, they all have 50 magnetic de-tents inside, making it 200 steps per revolution. There are same types with 400 steps per revolution, meaning 0.9 degree per step instead of the usual 1.8 degree per step.
There are also 3 phase and 5 phase stepper motors, Vexta had some nice videos explaining all the types and versions on youtube.

Many thanks to both.  Good catch 16, 17 not 016, 017.  That eliminated that problem then it said pin 16 was already in use.  I ommitted the "spindle out pin 16 and 17" then it worked.  
4th Axis Mill opened up.
Can't find control for the A axis and some of the other directional keys have been switched around.  Where would I correct them.
Mandy, Many, Many thanks,

Routerworks

We've recently suffered a problem on our DMG CTX 310, with an error on the HSCI bus. Had to change the PLC I/O board, which is not cheap.
Finding a generic drive for those servos might be a problem. If I were you I'd toss the Heidenhain stuff, make some servo motor mounting adapters and just get new servo+drive sets.
I worked on a project with some Leadshine EL7-EC servos and drives through EtherCAT (although not with LinuxCNC, but they could easily be integrated) and can recommend them. Very smooth motion, quick integration and easy tuning. I also used a Mesa 5i25 + 7i76 on another project and the Leadshine EL6/EL7-RS should work just as fine through Step/Dir.
Motors are compatible with both series (23-bit encoder). Big pluses of EL7-EC vs. EL6/EL7-RS is (to me) STO. Both series are relatively inexpensive.


 

delete the red text

and change lines like

net joint-0-pos-fb <= hm2_[MESA](BOARD).0.stepgen.00.position-fb

to net joint-0-pos-fb <= hm2_[MESA](BOARD).0.encoder.00.position

If you want encoder feedback (closed loop) rather than stepgen feedback (open loop)





# position command and feedback
net joint-0-pos-cmd <= joint.0.motor-pos-cmd
net joint-0-pos-cmd => pid.x.command

net joint-0-pos-fb <= hm2_[MESA](BOARD).0.stepgen.00.position-fb
net joint-0-pos-fb => joint.0.motor-pos-fb
net joint-0-pos-fb => pid.x.feedback

# PID Output
net joint.0.output <= pid.x.output
net joint.0.output => hm2_[MESA](BOARD).0.stepgen.00.velocity-cmd

# ENOCODER
setp hm2_[MESA](BOARD).0.encoder.00.counter-mode 0
setp hm2_[MESA](BOARD).0.encoder.00.filter 1
setp hm2_[MESA](BOARD).0.encoder.00.index-invert 0
setp hm2_[MESA](BOARD).0.encoder.00.index-mask 0
setp hm2_[MESA](BOARD).0.encoder.00.index-mask-invert 0
setp hm2_[MESA](BOARD).0.encoder.00.scale [JOINT_0](ENCODER_SCALE)

net x-pos-fb <= hm2_[MESA](BOARD).0.encoder.00.position
net x-vel-fb <= hm2_[MESA](BOARD).0.encoder.00.velocity
net x-pos-fb => joint.0.motor-pos-fb
net x-index-enable joint.0.index-enable <=> hm2_[MESA](BOARD).0.encoder.00.in
net x-pos-rawcounts <= hm2_[MESA](BOARD).0.encoder.00.rawcounts

# Home
net home-x => joint.0.home-sw-in
net x-neg-limit => joint.0.neg-lim-sw-in
net x-pos-limit => joint.0.pos-lim-sw-in

No worries, it is Linux and 19.3 still gets security updates and Firefox also updates regularly.
I have probably over 10 machines on 19.3 in daily use, connected to internet with no issues.

I'm currently running Mint 19.3 and the 2.9.0 pre-release with the 5.something RTAI kernel. Is there value in upgrading to mint 22.1 with the RT-preemtive kernel?
I don't have issue with version 2.9.0 pre-release but lack of 19.3 support concerns me since this system does have network connectivity for transferring files.
Thoughts?

forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77

Regarding robustness, I have downloaded new firmware to my IO card on a running linuxcnc system. It still works and comes back online. One can always wonder how good it was that it was away for half a minute. But nothing crashed, nothing stopped.

Thanks for that document. I had already looked into it and tested what you write there.
Unfortunately it wasn't sufficient on this mini-PC and these realtek network adapters to make the datagrams UNMATCHED go away.
On another system I have it worked fine on the builtin realtek driver though. If I remember, your settings worked on the J1900 I briefly tested.

I am aware of the coalesce settings, but I didn't have to set them to zero on the Intel cards. It worked fine anyway, they are at 3 usecs still.
When I come around to it I will set them to zero in the interfaces file.
I can't find a good way to enter non-energy-efficient mode. It doesn't seem possible (at least easily) to set it in the interfaces file.
If I remember it resets the interfaces when entering or leaving ee mode so nothing I want to do too often.

There are plenty of those mini PC but it is exhausting to search for them. They have product listings with CPU options that are dirt cheap, but after choosing the N100, memory and disk they cost quite a bit more. The one you list look alright, not that I need RS485. Found it on AliX as well. There is now the N150 which is almost identical to the N100. I wouldn't pay much more for that one, maybe a fiver more.

Hi Rodw,

I really hope Clive can use the planner with the plasmac application and even get a better result.

And yes the centripetal radius can be used to calculate cut speeds. Your approach should work ok.
If you need any additional hal pins, don't hesitate to request a feature.

For plasma's true hole technology we could also give a-axis, b-axis values to compensate kerf angle at runtime.
This is simplest solution that can be done by 2 tiny motors attached on z axis torch holder. A compensation range
0-15 degrees should be ok in x,y direction.

From that perspective we could also compensate the tp xyz position output so that
the torch kinematics stay valid, the tcp stay's valid when torch angle is compensated.

This are just idea's.

I will have to try your planner now
Yes, I know how hard you have worked to achieve this planner.

The theory I had was to calculate the cetripetal radius at a given cut speed so that we knew the radius below which the torch must slow down due to physics. Then we could apply some yet to be invented algorithm to the cut parameters. One idea was to stop managing the process control variable voltage to keep height stable, and we would lock the torch height and then alter current as a process control variable to maintain constant torch voltage. In this scenario, the kerf width should stay constant as the arc is negotiated. When you have perfected this planner, try that on your machines

Hello, today I had the opportunity to update LinuxCNC on this machine (it is normally not connected to the internet). I'm happy to report that the problem has disappeared!
Thanks a lot!