Advanced Search

The 7i96s is a drop in kind of replacement.
At the risk of adding far more complexity, you could consider Ethercat. There are some interesting options emerging. eg The Lichuan 4 axis stepper driver in a single package. I only hope I can get this going, Also available in closed loop. At USD $92 plus shipping, it competes on price depending where you live.

 
 

rodw wrote:

At least in Australia all this is illegal now. You can't make firearms parts without an armourer's license... Maybe our overregulation will save us.

This is the valid way to go I think. You cant make a weapon of a certain type without a license. Get caught, go to jail.

The printing thing is just a kneejerk: "omg you can make the guns cause of this new fangled machine... from 1986". You could always make guns off the radar. Yes, printing an unregistered weapon is certainly easier today than it was yesterday, but I don't really think the rules change here. Punish the people who commit the crimes, not everyone who doesn't.

This is also different from a lot of other dubious new efforts to control internet consumption for example. Printers literally CAN'T be controlled any more than a soup spoon. You can certainly harass buyers of brand new consumer printers, but that wont have any impact on making weapons.

As it relates to us CNC people, here is how the dual use laws have played out - a far more serious set of laws.  I cannot buy a VFD over 599hz because all the manufacturers have applied the law to their products due to the dual use export restrictions.... In canada. So I bought my VFD from vietnam. Yup... real good law there. Literally does nothing. zero, nada except annoy people that want high speed CNC spindles. I get the reason for the law too, and I even agree with the principle... but the implementation is utterly useless. You still need to track all your illegally exported goods the exact same way as before. You gained nothing you wanted from this law. (on a VFD, other items on the dual use list are more realistically managed)

 

It seems, this routine got no attention. You can do from 3 corner up to a lot, with rounded corners, configurable in the routine as desired.

forum.linuxcnc.org/42-deutsch/58236-g-code-schleifen#341677

Please share your hal and ini file. There are some settings required to enable the Mesa encoder inputs

How can you expect the 1 ms servo thread to work when it takes 1,6 Ms on average to talk to the card
Ditch the laptop! 

rodw wrote:

More than USB, laptops make poor choices for linuxcnc. Too much latency inducing stuff!
 

This is more or less a clone of a previous build I did, that works great. Same 7i96s and both are using a Lenovo Yoga, this new Yoga is a bit newer. The original (working) setup uses a Lenovo dock for the Ethernet connection, this new (not working) setup used the USB-C to Ethernet adapter.

BUT for a square with NO programmed corners, blend with arcs and parabolas are acceptable? 

This is hypothetical and the gcode is really bad, an error waiting to happen. You might as well attempt to cut a 7 pointed star and break things properly!
Time to get out of the office and onto a real machine!
You should be either looping the corners or adding fillets to the part. If you choose to write bad gcode, be prepared to suffer the consequences. Fixing that is your problem, not the S code developers.

PCW wrote:

The USB Ethernet adapter is likely the main issue here

Running:

sudo chrt 99 ping -i .001 -q -c 60000 10.10.10.10

in a terminal window will give you an idea of the latency of the hosts Ethernet interface

( The command will run for 1 minute and then print timing statistics )

 

jeff@SM10:~$ sudo chrt 99 ping -i .001 -q -c 60000 10.10.10.10
[sudo] password for jeff: 
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

--- 10.10.10.10 ping statistics ---
60000 packets transmitted, 60000 received, 0% packet loss, time 102174ms
rtt min/avg/max/mdev = 1.297/1.631/3.302/0.044 ms
jeff@SM10:~$ 

Comments please

More than USB, laptops make poor choices for linuxcnc. Too much latency inducing stuff!

ok wrote:

If you think this is on one hand not real and unworkable, but one the other hand suspect that they are "hiding something else" - What do you have in mind that they (whoever that is) want to achieve?

The dangerous precedent here is that one unelected official is given the power to do everything so there is a hidden transfer of control away from elected officials.... so it will be expanded. Fortunately, it has been banished to a committee from which it will likely never emerge...

At least in Australia all this is illegal now. You can't make firearms parts without an armourer's license... Maybe our overregulation will save us.

I think that's exactly what I was looking for, and wish I had known about it years ago

Now to see how well my configuration plays with it...

Thanks!

You could use Halscope to see what the F-error actually is, then set the limit to some arbitrary factor of that. It wants to be high enough not to trip when there isn't a problem, but to trip if something actually is stuck.

The issue indeed did turn out to be related to spindle-at-speed.

Was able to fix it by ensuring spindle-at-speed was set true during tool changes.

You can't use names= and count= at the same time.
if using HAL_TWOPASS then they all need to use names=

In your example the correct syntax is:

Home-made spindle encoders can be as simple as a slotted disc with 3 x opto sensors (like: www.amazon.co.uk/YOUMILE-Optocoupler-Sen...rduino/dp/B07TZ78N8W )

You need to make one slot a bit deeper so that only the index sees it, and arrange the others around the perimiter so that they are N + 0.25 apart. (not N + 0.5 as I once did when making an encoder)