Advanced Search

This is mysterious. After I had success with the windows PC I tried another harddrive with a Windows in the linux computer. I could ping the card from windows.
So the Ethernet adapter seemed to work.

Now I re-installed the Linux hard drive and suddenly it worked again. I did the static IP address 10.10.10.1 and set the jumpers down/up.
Only idea I have now that the network adapter was in some weird state and that it was re-set after disconnecting the power and re-booting.

ping times are about 0.5 ms

F11 toggles full screen so you can move it around

sudo chrt 99 ping -i .001 10.10.10.10 -c [count I am testing]

you must have recently done an update? the var file as well as the subroutine folder requires updating. ALWAYS check the status page after running an apt update as sometimes when major changes are implemented in probe basic the configuration files will require updating. this is one of those scenarios.

to verify you can install meld (sudo apt install meld) and run a directory comparison to see the files that have changed in the configuration folder and subroutine folder.

once you complete the updates you should be back to normal operation!

I don't think that I have ever seen a motorised tailstock for drilling. Every example that I have seen used toolpost-mounted drills for feed-per-rev drilling.

Fusion probably can't be persuaded to use Y as it won't believe that Y can be parallel to Z. You _might_ have more luck with the tailstock axis as W (supplementary axis parallel to Z)

That said, the postprocessor is just Java, I would have thought that it was possible to make anything happen in there for specific G-codes.

oh hang on, we must call them "makers" now eh.

dear friends .... unfortunately I think this is our fault.... we played a rigged game.... someone taught me that you don't play rigged games .... for now we have to use what there is .... so let's use the "makers" as long as they are there .... I have doubts they will last a long time .... this kind of people, if we continue like this ... I don't know if they will be there in the near future ..... in my house they have already almost completely disappeared ..... too much effort .... think next step of that game is produce only "ia expert" ....

But is an hevy argument of discussion so prefer stop it here. I'm not able talk on these in correct languages.

nice.. have you considered simply adding the probing tool number parameter to the toolchange call with an if statement? this way anytime you load or unload the probe tool it would activate a subroutine to either deploy the probe or retract it?

interesting concept on the ride along design. that is going to add quite a bit of unbalanced weight to the machine maybe? have you considered how that will affect high speed motion and inertia differences for the slaved drive motors?

I am about to release a fully integrated RACK type atc integration for probe basic, this could be a simpler and more economical method for atc maybe?

I think that you are likely to need some I to pull in the last bit of error. Have you tried adding I (very small numbers, .00001 maybe as a starting point)
Are the servos operating in velocity mode or torque mode? (ie, is there a velocty loop closed by motor tachometers)

First thing I would do is setup the LinuxCNC host computer with a static IP address of say 10.10.10.100
 This is most reliably done by editing the interfaces file as described in the hm2_eth man page:

man hm2_eth

Then after rebooting (or setting the interface down and then up) verify that the host Ethernet device
is set to the 10.10.10.100 static IP address with:

ip a

Then set the FPGA card to a 10.10.10.10 IP address and cycle its power.

finally check that you can ping the card:

ping 10.10.10.10


 

Sorry for the late reply.

I think that you can just load two carousel components.

loadrt carousel names=left, right

for example.

Then you can enable the relevant carousel inside whatever handler script / subroutine you are using. Presumably based on the tool number? 
I guess you will need some logic, if only to work out where to move the spindle to pick up the correct tool. 

Handling a random toolchanger, where the tool can swap between carousels would be rather more of a challenge. 
 

papagno-source wrote:

Note: Using LXRT realtime

 

Interesting! Are you using RTAI + uspace or Xenomai? I don't fully understand how to make LXRT work, or how to compile the wrapper applications. 
(Which is a bit of a problem if you are the release manager) 
 

What is the last MX version? did you try that version?
The latest version should work with just\
sudo apt install linuxcnc-uspace
But that would be 2.9.4 , not Master, so a manual upgrade would need doing
All this is based on it being a Debian derivative, so it might not work.
Just in case you are still trying to use the old how to for the 19.4 version, don't, it will not work on latest versions, as far as i know.
-
It is advisable to use Debian 12 or 13, or even Linux Mint Debian Edition 6, as all that is required to install LinuxCNC on them is the single command mentioned above.

Hello everyone, I’ve been trying to install master Linuxcnc, with mx 19.4 or mx23

Although in the past, I’ve done it seamlessly, currently I’m having huge trouble with dependencies because no matter if I activate the system or not upon installation, I always have problems with libudev or libgtksourceview.

if I try to remove the current versions, which are not compatible with Linuxcnc, i’ll end up removing other programs and creating even more dependency problems. Although I can install the version that linuxcnc-uspace wants for libudev, if I do it , it will remove other required software. Same for the other dependencies…

i’ve followed the guides, but I always get stuck with this problem. Does anyone have a different approach to resolve this?

thanks in advance

now i have another error message?


 

I am facing a very similar situation. (almost identical to the above descriptions)
I had some issue with the Linux installation to do apt-get, so today I tried to install the latest ISO image new.

Then the Mesa card was not giving any response at all.

I tried lots of different things. Now in my desperation I tried to ping the card from a windows computer and the 4 green LEDs on the 7i95 start with some life signs) aa ping. 192.168.1.121 gives me responses.

Verdict: Probably some mishap with the networkadapter on the NUC PC.

Any advise how to narrow down the Ethernet problem on the Linux installation?

I can also change the card to 10.10.10.10 and ping it from the Windows machine.
My assumptions

• 7i95 card seems not to be damaged
• 5 V power seems O.K.
• the patch cable is not causing the issue