Advanced Search

No double posting.
The other topic deleted.

Try adding this function:

apt-get update
apt-cache search linux-image

shows a newer kernel:  linux-image-6.1.0-20-rt-amd64  PREEMPT_RT

Hmm. I wonder... would that be compatible with the stock linux.292 distro ? Should I try the kernel update? Feeling luck punk?

Funny thing... the networking appears to work fine (but sure, browsing and downloading is perhaps not as time critical as CNC control!)


Update: Went back and checked ping with the older PC and the same MESA card.... results are consistent around ~ 0.4ms.  That seems much more like it, and seems to further confirm the MESA card is behaving correctly.
 

Reported kernel is: 6.1.0-18-rt-amd64
 

Thanks for the pointer at least I now know what to look at. I tried manually uploading the config file but tftp timeouts (ascii & binary modes) as well:

tftp> status
Connected to 10.10.10.10.
Mode: netascii Verbose: on Tracing: on
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> put /tmp/config.txt
putting config.txt to 10.10.10.10:/tmp/config.txt [netascii]
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
Transfer timed out.

I will download the remora source plus the build system to add some debug messages and  hopefully identify what is happening.

The latency test only checks dispatch latency, it does no I/O.

The long and consistent ping times will make operation impossible
(at least at a 1 KHz servo thread rate) Not sure what is causing that,
not something Ive seen before.

The CPU speed issue includes the latency histogram, it doesn't display
there either, as expected:

 


I wonder if the distributed kernel is too old for the N100?

I'd like to write about my experience with the unspeakable Asus PN 50 E1 barebone PC with AMD graphics, for those who are interested.So in 2021 I made the same mistake for the second time in25 years by buying another PC with AMD graphics. The second time, too, thermal problems occurred sooner or later.I can't say whether the issue with OpenGL is causing the thematic problems, but with a little research on YouTube you can find videos that deal with similar problems to mine.The fact is, however, that the Mini PC has terrible cooling. Well, how can it be well cooled when everything is so small?There is indeed very, very little space to get anywhere near decent cooling. In my opinion, the ASUS engineers didn't make much effort to cool the CPU even remotely well. In my opinion, the whole cooling concept looks like planned obsolescence.I disassembled the PC and studied the cooling concept. I doubt that this small radial fan can really draw cool air into the case from the outside. If you only know a little about aerodynamics and/or ventilation, you realize that the fan can't possibly draw in air efficiently through all these slots and air gaps in order to dissipate the heat from the processor in the cooling element.I have now removed the grilles and nets from the housing openings for the intake and exhaust.The transition from the CPU to the cooling element did have heat-conducting paste. The question is of what quality was it? How good is the cooling element?The intake side of the radial fan is just 4mm above the components soldered on the motherboard. If you know that a fan should have a trumpet-shaped intake side and see here that there are only obstacles and sharp edges at the intake, you know or suspect that no air is transported here but only circulated and gets hotter and hotter, which is the reason that the CPU temperature rises from 53 to 88° within 15-30 seconds. Crazy, isn't it?Now I will have to make do with the modified inlet and outlet openings and newly applied heat-conducting paste. That will have to be enough to keep the thermals constant, otherwise I'll have to get a new PC.

thanks for the answer, I've been looking at the extrajoints configurations, I missed something before and that is that I don't need to use GCode, just update the joint.N.motor-pos-cmd values from the GUI so that the joints move to the new measurement, thanks

Hi Spumco!
Yes, I am just designing the PCB that’s controls it. The bottom part (plc user buttons + normal stuff like start, stop, coolant on/off, etc) goes to the ethercat board. The keyboard I made a USB board that connects directly to the pc and it is seen as a normal HID keyboard but it sends “special combinations” for menu select, machine and so on


regarding the $iemens like modifications it is comming along really well! Not finished yet the new version but basically I got rid of the INI file, made a parameters table (machine, channel, axis), added support for multichannel (basically you can control group axis in different channels and run different gcode in each at the same time (for example in twin turrets lathes). For doing all these stuff I basically rewrote the cnc, everything in C++ (got rid of C as each channel is implemented as a C++ class). Got rid also of NML (replaced by zeromq and capnproto) so it is easier to add new commands as NML is a good but old piece of software. Replaced the rs274 interpreter for a 100% $iemens compatible one so now I have all nice commands like goto, gotof, gotos, repeat from to, etc… 
I removed the o#number thing! This was what I hated the most! Also now subprograms are just searched by file name in same directory structure as $iemens, (current dir-> spf dir-> cus dir->…) 
concerning to GUI I am finishing adding “countour gui” for graphically draw a contour and write gcode automatically (check attachment)

when the project is more advanced I will post more info and tests 

bye!
Franco

I'm looking at the histogram image, but feeling a little lost.

How to interpret the results... how to deduce the CPU speed ?

It looks quite tidy. None of the outliers I recall from before, so maybe that was a bogus memory
I guess the histogram is explained in the docs or here somewhere- will have a search for an explanation that clicks with me.

Regarding the slow ping rate to the Mesa card... that feels like it should be an issue, and could also explain the failure of the HAL test to detect the switches changing state...?

Does the latency test communicate with the MESA card over the network connection, or is that latency test purely between the CPU and software?
 

The networking cards are:
qty 2 of RTL8111/8168/8411  and 
qty 1 of RTL8821CE wireless

All are operable from within linuxcnc desktop, although I disabled the wireless and unused LAN port after installing things, in-case that might help (though it didn't seem to make a difference).

The histogram result is attached. I've also added 6 more images to the original google photos link above. (both before and after running 6 cogs).

Finally, the ping result is also attached.
That seems odd (and maybe another clue?)... why is a local ping taking longer than ~1.4ms... Maybe it's supposed to for the Mesa card, but makes we wanna go hmmmm.... 

Thank you @rodw

Some extra info for clarity:

The "Get CPU Speed" is a button, which when clicked requests the OS user password, and then fills out the value (792 MHz in this case).

By comparison, when using another PC (the old Pentium), clicking that same button retrieves the correct speed for that machine (1800 MHz as I recall). - That is the reason I wondered if the MesaCT software was unable to read the correct CPU info from the mini-PC, for whatever reason.

But that said, the other elephant in the room is the HAL test failing to respond to the button presses, which could be just related to the speed issue, or maybe suggest some other more general comms issue, perhaps with the ethernet control chip in the mini-PC.

I will get to the machine, grab the Realtek type number, and also re-run that latency-histogram, and post the results. I recall seeing odd outliers compared to the pentium, but silly me, I didn't take a photo at that time.

Thanks Phillip! I thought of something to try and hopefully I'll be at the machine later today to try this. If I re-set the safe height from the prefs after changing the range in the USER_COMMAND_FILE then I think it should work fine.

So then the user command file would be:
I'll let you know of that works, so no need for you to try and come up with something for now, but thank you!

Scott

That number is not really the cpu speed. To see it, type
latency-histogram --nobase --sbins 1000

So what is it? TMAX reports performance in timer ticks, not MhZ so it does some maths to convert it to MhZ.
The servo thread takes 1000 usec, We want the Tmax to be < 70% of this so there is some overhead for latency.
I have never used the program you are using as its not part of linuxcnc. . Looks liike its converted TMAX to MhZ. CHeck some of the other drop downs.

hello guys,
i have 5 axis milling cnc machine and i want to use tool setter to measure the tool length, i am using versa probe and m6 remap ngc code as given from qt dragon documentation  (  linuxcnc.org/docs/html/gui/qtdragon.html#_auto_tool_measurement ) , what i expected to be done is as follows:
1- Manual Change tool
2- probe down to Tool setter
3- calculate the tool length
4- update the tool table

what qt dragon do is that it needs the probe height and workpiece height  and calculate the distance between them to be able to set the the tool length by using this equation (Probe result - diff between probe height and workpiece height), from my knowledge in tool length meseurment there must be tool length reference and the tool length is the diff between tool reference length and the tool length measured. i want to calculate the actual tool length.
can someone help me it has been 2 weeks stuck in this problem !!!