Advanced Search

Important to remember this is JUST rage bait, and not real.
They literally aren't banning anything, they are proposing a restriction that is not workable even if it got passed, which it won't.

Should you be concerned at their lack of knowledge to understand their own laws? Yes. Should you be concern this will somehow impact your printers or CNC's? No. Should you be concerned this will make linuxcnc disappear? No. That's literally not even possible.

You need educate your local government if you see bills pop up like this, they are clearly clueless. Responding as if this is an existential threat though is just being as silly as they are and not in the least bit helpful.

My opinion is that this proposed law is SO dumb that it is hiding something else. Follow the money as they say. Who benefits from this? It's not gun safety advocates.

grandixximo wrote:

 we are limited to what we can do. 

This statement does no compute.



 

There are no constraints on HostMot2 FPGA pins, any pin can be any function
so a 7I74 ( 8 channel RS-422/-RS-485 interface) can have any mix of functions
that physically match the 7I74 pinout. That is, for example, you could have
SSI,BISS,Fanuc absolute encoders are sserial mixed on the same 7I74.
You could even have Step/Dir outputs on output channels and say period
measurement on input channels.

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.