Advanced Search

A well deserved award. And thank you as well for what you do for this community.

And yet more. call it rage bait if you want. Remember this isn't just about 3D printers  it concerns ANY machine Additive 
or Subtractive. 

I was not getting anything on halshow and then I used a multimeter on the encoder and did not get anything. I thought it may have been damaged so I ordered another and hope to install it Sat or Monday.

sataran wrote:

... i wanted to know if it is possible to have both a biss signal on a port and a normal serial on the other port on a single 7i74?

I would venture a guess at Yes it is as i have something similar in use for many years, details here
forum.linuxcnc.org/30-cnc-machines/31792...-01-retrofit?start=0
There should be attached two firmwares for 5i25/7i77/7i74, one with 4 SSI and 4 SSerial, and another for 6 SSI and 2 SSerial, look for posts made by PCW if you think any of that is helpful.

If you can justify it, Mesa 7i96S.
For very cheap use an old PC with a parallel port, or a new-ish PC with a parallel port add on card.
Both versions are extremely reliable, proven by many machines in daily use.
Depending on requirements, parallel port might limit the maximum speed, still very usable always.

I finally got CSS working on the lathe. I ditched the vevor vfd and bought a Huang yang vfd. It had way more features. I connected it through modbus instead of the EC500. It works perfectly now in CSS

alright i got my encoder biss running! i started to assemble all cards and i wanted to know if it is possible to have both a biss signal on a port and a normal serial on the other port on a single 7i74?
if it is not possible i will use another solution but if it is a possibility I'll need a different bitfile.
my configuration is :
6i25
P3 =>7i76
->spindle -> variator - > motor
->field out 0 7 -> 4contactor
->field in 0 15
P2 =>7i74
-> biss
-> 7i87
-> 8i20

The jerk limits are being respected on the tangent trajectory, the jerk limit works on segments due to the tp architecture, you see jerk spikes because when you look at the joints indipendently, the jerk they experience is completely different from planned jerk, there is cartesian rotation jerk, there are kinematics transitions, the spikes being reported are due to the fact that how the jerk is implemented and the architecture of the tp, we are limited to what we can do. When users report spike and we try to fix them, we find that the problem is not our jerk limiting, it's everything around it that is not made with jerk limit in mind...
The reasoning behind "augmenting" the path, is that we don't like to see the machine ondulate, on something like a multi axis cloud point, we can do it very smoothly but not at constant velocity, look at the actual machine and you'd want to fix it too. Do you want to see nice curves in the scope. Or you want to see the machine behave like it's following a smooth path?  Swift motion requires a swift path, they go together.

Which controller board is best to use with LinuxCNC? I have a 3-axis router. DM542 stepper drivers and Nema 23HS9430B motors

Thanks for the clarification, Hakan

Thanks, Rod, for your fast answer.

I have a general question regarding following error (FERROR) when controlling servo drives via EtherCAT.

Is there a generally expected/inevitable following error caused by the EtherCAT cycle time (latency/jitter), even in a properly configured system?
Or would a noticeable following error usually indicate a configuration/implementation issue?

For reference: my servos are tuned and run with a very small following error of about 20 encoder counts in the Delta software (24-bit encoder, so basically negligible).
However, in LinuxCNC the reported following error increases with speed and can reach about 1–2 mm.

What would be a typical/acceptable following error range in a properly configured EtherCAT servo system? Any ideas?

rodw wrote:

I thought jerk limiting was purely about acceleration. To extend it to varying the path seems to me is really scope creep. Get it working without changing the path and include path optimisations at a future time and write better gcode for now.

jerk limiting may permit higher maximum acceleration. Currently MAX_ACELERATION is set from a combination of motor dynamics and physics by the machine builder Eg the inertia in a heavy moving table may require a lower acceleration than what the motors are capable of so they are not overcome by inertia on deceleration and cause following errors. Its probably valid on a jerk limited machine to increase acceleration. In this context, some violations may be valid.

Absolutely correct. 
It is a constant fight to keep people from mixing jerk - 3rd order motion - with G64 constant velocity algorithms. These are 2 entirely independent topics and should be kept as such.

One thing I also keep seeing is the idea you just "augment" the existing trajectory for jerk limiting - rounding corners and such. This is not gonna be the route to success. Jerk (snap, crackle, pop - yes those are the real terms) needs to be in the core motion planning with velocity and acceleration.

grandixximo wrote:

You cannot maintain velocity, follow the exact programmed path, AND have smooth jerk.

This is physically impossible. What I am saying is I would sacrifice velocity rather than programmed path on G2/G3 programmed arcs. At the moment if you run something with tangent arcs even with G61 the velocity is kept, this messes with jerk. G61 with jerk will have to slow down more.
For many line segments G64 Pxx it also slow down more, the more tight the tolerance, the smaller blending arcs the slower you have to move.
Béziers will give you better speed, because you can run them faster, but they are NOT arcs, meaning when you program a square for example, just 4 lines, you set G64 to 0.5 let's say, what kind of path error would you accept? A 0.5mm perfect radius which I have to slow down more to make smooth, or a squashed up Béziers which I can run faster?

Considering option 2, your set your priorities.

So for example the P value says you need to stay within 0.001mm, then that is your upper restriction for corner rounding, no matter what method you use. your lower restriction is then velocity.

So if I'm taking a corner at 20m/m and my p value and acceleration/jerk values mean I need to slow down, I need to slow down. HOWEVER, if I am taking the same corner with the same p value but only moving 1m/m then the p value is reduced until we hit 1m/m. You do NOT automatically round all corners up to the P value (something i think grotius' version did).

But like I said, I would focus on option 1, and when that work, fully, completely, bug free, we can look towards a new ground up TP with multiple jerk limited constant velocity strategies and more advanced look ahead (which is kinda what tormach did for the 1500).

The brother speedio C00 is a good example to look at. They have SEVERAL constant velocity modes you can choose in g code depending on the operation. some hold tighter paths for finishing, others hold higher speeds for roughing.

Another one to look at is fanuc and siemens, who use spline fitting.

But like is said, this should not be the focus right now. This is phase 2.


 

What I mean it it becomes development hell and the project dies, and it is the least critical part of the system we need.

Sure, it is absolutely what we want in the end, but getting there is just not happening.

Option 1 is likely a completable project and "good enough for now".

Peter at Mesa has had the XY2-100 galvo protocol working for quite some time:

forum.linuxcnc.org/additive-manufacturin...ead-protocol-xy2-100

Doesn't use LCNC but it could be easily converted with little effort: sls4all.com/  
It currently uses Klipper.