Advanced Search

I can not find Borax here, nor Boric acid, nor KCl, nor well anything really, even IPA i have to ask friends that own shampoo making factories for it.
But we have 18% HCl and 25% H2SO4 anywhere... and you can buy ammonium nitrate in 50KG bags for 20 Euro! With no permit or any paper!
I can not build a hobby rocket nor get rid of the bugs (every spring tiny flying ants, by the millions), but blowing up half a city is easy!

At the top of the gcode file add:
G64 P0.1
for metric machine or
G64 P0.004
for imperial machine,
that will deviate 0.1mm from the original line, or you can change P values as you need them

Hi all,

I'm having an issue with LinuxCNC not completing the entire command as written in the G code file.

Here's a piece of the code:
G0 Z1.0000 
(PASS 1)
G1 X-2.3750 Y2.7250 F8
G1 Z-0.0500 F4
G1 X-2.3750 Y1.3915 F8.0000 
G3 X-2.3738 Y1.3811 I0.0211 J-0.0029 F8.0000 
G3 X-2.3585 Y1.3750 I0.0112 J0.0058 F8.0000 
G1 X1.7250 Y1.3750 F8.0000
G1 X-2.3750 Y2.7250 F20
(PASS 2)
G1 X-2.3750 Y2.7250 F8
G1 Z-0.1000 F4
G1 X-2.3750 Y1.3915 F8.0000 
G3 X-2.3738 Y1.3811 I0.0211 J-0.0029 F8.0000 
G3 X-2.3585 Y1.3750 I0.0112 J0.0058 F8.0000 
G1 X1.7250 Y1.3750 F8.0000
G1 X-2.3750 Y2.7250 F20

If I single step the code, the command is completed as written. If I let it run, it completes MOST of the command and then it starts on the next command.

See pic.

 

Our borax doesn't go away due to evaporation, but we do lose some to drag-out when we're too impatient to drain parts and scrap in to the table.

Problem with borax is that it doesn't mix well; we've found heating up a couple gallons in the house and dissolving it works.  The concentrate can then be poured in the table and it mixes up ok during the drain/fill cycle.

I worked again at the spindle.

I have a “theory” on how to handle the two gearings of the machine.

First, I try to get the motor RPM into LCNC. With the analog out from the VFD, I am now able to get this with an accuracy of about ±25 RPM, which is less than 5% off. I measured the real RPM with a cheap optical tachometer and the RPM that the VFD “thinks” it is at. These two were consistently very close. The VFD was consistently 3 to 5 RPM higher than the tachometer, in an RPM range from 880 RPM (at 30 Hz) to 2080 (at 70 Hz). 3 to 5 RPM seems close enough to ignore that error and believe the VFD.

Now, having the motor RPM, I set the variator by hand so the overall reduction ratio was 1:1 (or close to it)

My plan is to tune the PID at this point and later multiply the error term (pid.s.error) by the overall reduction ratio. If I am not thinking about this totally wrong, this should give the system a hopefully somewhat stable spindle PID over the very large reduction that the backgear and variator provide.

Now I do have 3 problems:

1: There is something wrong with my pid.s setup. As soon as the error gets significantly negative, the output shoots up and the system runs away. I found that pid.s.output can be between 3000 and -3000, but I use 0–10 V, not ±10 V, so as soon as pid.s.output goes negative enough, it runs awaythe sign seems to be ignored. I think this has to be a somewhat common problem with 0–10 V. I was able to remove the runaway by using a limit component to cut away the negative part of pid.s.output, but that led to strange behavior as well. With this, I can increase P to large values without it starting to oscillate much.

2: I was able to get the motor RPM, and I have the spindle RPM, but putting both into a div2 component gives 0 at all times. And not a close-to-zero float (e.g. 5.459834658e-7), but actually just 0. I thought it had to do with the deadband, but no value of that seemed to resolve this. The spindle RPM is obviously 0 when the spindle is still, so I do have a limit component to keep the spindle RPM at ≥ 1, resolving divide-by-zero issues. And as soon as the spindle spins, the numbers seem fine.

3: I already foresee a future problem: given that I have the gear ratio and a solid PID at a ratio of 1:1, I would need to scale pid.s.error (reduction_ratio * pid.s.error), but I could not find where this variable is set, so I would not know how to set my scaling factor.

Sorry for this long rambling message, I hope I was able to explain what is going on on my side.

Thanks

Just to tidy up this thread, here is a pic of my working PB Lathe setup...

 

But the main question is still open: is there any way to tell the backplotter where the centre of rotation is, when the rotary chuck is not at machine Y=0?

In my case the chuck is fixed at Y=700mm. The backplotter always rotates around Y=0 (machine origin), so the wrapped toolpath displays as a large circle far from the actual machine envelope instead of showing correctly near the chuck.

I have already seen the 2013 thread where andypugh said there is no solution.
Is this still the case in 2.9.8, or has anything changed since then?

Yes, for hal scaling and output and encoder count direction, but i do not know if that works for geometry.

I use baking soda as rust inhibitor, it does a pretty good job and even when water evaporates, it does not, so adding more is not necessary for a long time.
It also remains attached to slats/table when no water is left, so had no rust issues for many years.

grandixximo wrote:

I've used debian 10 11 and 13
I skipped debian 12 this is for internal timing release reasons, not because 12 had anything wrong with it. I did not notice on my hardware considerable differences between debian releases. 

I don't really see any difference between 12 & 13 (everything is 13 here). From earlier feedback on the preempt_rt email group, The preempt_rt network latency issues were most likely introduced in kernel 5.9 and Debian 11 had 5.10 but because Linuxcnc never released anything on 11, the issues did not  appear until Debian 12 which I used from the original beta release.

grandixximo wrote:

I'm also on the discord, and I am fluent in Italian 

discord.gg/WwMfD9v9M

If your Italian friend wants to hop in, I'll be glad to help him out.

Thanks I've passed that on. He'll probably call himself frk (Francesco)

This is not related to the phasing.
Or perhaps it is, on the way that clocks have started to run with different speeds.

You can switch on debug "ethercat debug 1" and watch the DC time difference between slaves slooowly converge.

It's part of the startup of slaves
gitlab.com/etherlab.org/ethercat/-/blame...e=heads&page=2#L1480

The server issues 5000 sync requests, one every millisec, and waits until clocks are within 10 microseconds.
If they aren't, you get the message. The slaves' clocks will eventually converge.

I had this issue, was unable to fix or even poke at it, and then suddenly it went away.
I suspect it has something to do with ethercat master version, but since I was unable to
diagnoze it, I really don't know.

I'm also on the discord, and I am fluent in Italian 

discord.gg/WwMfD9v9M

If your Italian friend wants to hop in, I'll be glad to help him out.

I've used debian 10 11 and 13
I skipped debian 12 this is for internal timing release reasons, not because 12 had anything wrong with it. I did not notice on my hardware considerable differences between debian releases. If you have issues please share your configuration, be clear about the issue, share as much info as you can, and if you are not using my fork code, you most likely HAVE phasing issues. Those maybe effecting OP times, or motion, or nothing, it depends on the hardware. Will update to my fork fix everything? No, most definitely NOT everything, but I am sure phasing will be as proper as it can be on your system, and you will have debug pins to analyze performance which you can share, run halscope and halshow, see the ecat.0.xx pins, so that we can get to the bottom of the issue.
If Scott was still in the game, he would probably merge it and make a release. I would advise everyone to update, and if you have any issue, I will be here or on GitHub for support.
 
TL;DR
My fork does not magically fix all issues, but it does fix some, and gives you pins to benchmark your setup. Please build and install my fork, then test, and share your configuration and test results if you have issues and you want help.

I think 4" deep is enough even less if you have to. I found best quality was with the water touching the bottom of the plate (to 5mm below) but often evaporation took it down lower. Enable preflow to get air flowing before starting a cut to blow the water away from the torch. Using commercial quench, I only emptied the tray every 6 months or so and just kept topping it up as the active ingredient does not get lost.