Advanced Search

I can make it happen by:
MDI: M3 S100
manual stop spindle
MDI: M70
MDI: M72

Spindle starts.

Well that masks the problem, and in some probing the spindle should be on.
But I agree we need to protect the user in the mean time.

This is one of those deep seeded, need to look at the big picture problems.
We aren't very good at those

rodw wrote:

Cant do this anymore bye all wrote:

So yes it would be a hell of a lot of work for rod.
It won't be cos  I ain't doing RTAI
 

hahahahaha

It allows you to align the electronic Z axis to the tool axis.

Cant do this anymore bye all wrote:

So yes it would be a hell of a lot of work for rod.

It won't be cos  I ain't doing RTAI

Using a Fanuc control with G68 and G69 enabled you can rotate the working plane in the control. This allow you to align the tool axis (electronically) to the tool axis then program the part using print dimensions shown at the angle the view is drawn. You would program a rotation of one of the three rotary axes (depending on the machine rotary axis motion) using a line of code G68 X Y Z A B C (according to the programming manual.
Then, you would program a rotation of the second rotary axis using a second line of G68 code.
You must determine which axis to rotate first to have the work piece Z axis properly aligned with the tool axis.
Heh, now you must align your brain with the machine to be sure you move (program) the axis motion in the proper direction. A pretty neat trick.

G68 X Y Z A B C
G68 X Y Z A B C

then cancel the whole mess with a G69

In 15 years of running the Viper 5 meter bridge mill with a 15mb control I used it a total of one time. The machine has a 5 meter X, 2.5 meter Y, a 1 meter Z with BC head with +-120 degree B and infinite C axes motion. As the owner of the shop I tried the G68, G69 programming as a test. I determined it worked just fine except the confusion principle. It was much less confusing to program the needed motion using a CAD/CAM system and not worry about the operator losing orientation. G68/G69 was never used during production.

My LC2.9.2 is running nicely on a Raspberry Pi 4B with AXIS.
But, it will not accept multiple MDI commands.
I used to be able to do this on the earlier LC2.8.4.

Spent some time checking ini and HAL configurations, and Forum searching, but no joy.

Suggestions ?

John

Alright I figured it out. I didn't read the output text when the installation had errors. The confirmation text said a bunch of stuff about not approving the use of 'abs' in the text and that I should include 'stdlib.h' .

I know nothing about writing components but it was simple enough that i figured i'd add stdlib.h somewhere in there. So i did and bam. It installed correctly and also does all the math correctly.

Thanks for the component Andy.

I spent 2 days learning to use classicladder and made a 3 state comparison exOR gate. After failing to find a way to math the gear ratios i decided to look at gearbox.comp again and figured it out.I ended up learning a lot for not reading an error text.

Muftijaja wrote:

Thanks for your doc, meanwhile I changed to the internal Intel 82579 network adapter and the jitter grows worse. 
 

Please type man hm2_eth and ensure the network settings for coalesence are set up.

Yes, they seem to have broken something with a new version. I have logged an issue and have received a reply. It will get sorted.
We add their repos to apt sources as a convenience to users that use ethercat. The error should have no affect (unless you need ethercat)

In the plot widget, to automatically reload a file when an offset has changed you could maybe use the fingerprint
For example:
files.catbox.moe/5km48d.mp4

I find it far easier to connect directly from the Debian file manager to a windows share, no need to setup a samba server. All is required is to have the gvfs packages installed.

Or use the file sharing that is part of a lot of wifi AP\Routers, use that as an intermediary drop off point.

It would only make sense if you are using GPIO/software stepping. SPI & Ethernet work fine on the RPi4. And honestly there are far better options, performance & price wise than any of the RPi variants. The only plus side is the physical size of the device.

Who's going to take up the mantle of building & testing the kernel ? The x86 variant is not 100% yet. Then there is the issue whether the RPi kernel has a matching RTAI patch. Then the RPi5 would require another kernel to be tested. So yes it would be a hell of a lot of work for rod.

forum.linuxcnc.org/ethercat/45336-etherc...tep?start=210#306237

Jitter is good, even for software stepping so move on.
You can also try
latency-histogram --nobase --sbinsize 1000 --show
to check if there are excursions in latency.