Advanced Search

Thank you Tommy,
You were right that that was the PATA setting in the bios.  I changed it to AHCI, and now that interrupt is no longer on the list anymore. 
 
Unfortunately, it doesn't appear that was the cause of my jitter.

Now the only things causing interrupts are
18 - Radeon HD 4250 internal graphics
LOC - (Local timer interrupts)
RES (Rescheduling Interrupts)

Is there anyway to see what causes the RES and LOC timer interrupts to see if the jitter is caused by one of those?

Sometimes 19 also happens, but it doesn't seem to sync up with times that the jitter has variance.

For some reason the nosmt=force setting in the kernal boot parameters doesn't seem to work anymore with the rtai kernel.  Should nosmt still work in the rtai kernel?

I have the following settings in:
ro quiet skew_tick=1 nosmt=force mitigations=auto,nosmt irqaffinity=0-1 kthread_cpus=0-1 rcu_nocb_poll rcu_nocbs=2-7 nohz=on nohz_full=2-7 isolcpus=2-7 intel_pstate=disable idle=poll cpufreq.off=1 intel_idle.max_cstate=0 amd_idle.max_cstate=0 processor.max_cstate=0 nowatchdog nosoftlockup acpi_irq_nobalance noirqbalance

I'm also using the irq affinity script from:  forum.linuxcnc.org/38-general-linuxcnc-q...ead-and-irq-affinity

Should I try a pci graphics card instead of the Radeon HD4250 integrated graphics?  Any recommendations?

That fixed it.

Now I need to add a section to match the pocket to the tool when putting away the tool.

Update:
The machines works again, without unexpected real time delay and a very good latency, but i had to take the PC of my Lathe. (the lathe machine uses the Mesa 7i76e card)
That PC has a on-board graphic card, but i first tested it with the VGA that was already there and i got the same latency issues. As soon as i used the on-board vga, the latency was perfect and no "realtime errors" at start up.

I have started latency-histogram, with 4 x glxgears and a youtube video running for about 1 hour.
I first started the histogram, then opened one glxgears and waited to check if anything spikes happen. Then i opened 3 more glxgears. No latency spike. Then the youtube video and the pc was running like that for almost one hour without any change to the base thread.
On tomorrow i will run a milling program and check if anything bad happens.

Also i will connect that "latency issue PC" to the Lathe and hope there will be no problems, but i think with the Mesa card there shouldnt be any.

Arciera is hard working to try out new non-linear solvers

I'm afraid that is a bit of an overstatement, I have no experience with this and also not really the time to poke around in dark any longer. This requires somebody who actually knows what they are doing, at least somewhat.

What is needed is a robust numerical solver and then the next step is the max error fitting described in the paper.

More pictures, inside the control boxes also.
-
This is absolutely a 3 axis machine mounted on a long linear axis, see my pictures, everything in white is that 3 axis machine, everything in gray is the long axis.
There are no resolvers on my machine, it has serial absolute encoders on all axis, grayscale coding and ac motor with clutch on the tool changer, pneumatic brakes on the long axis, electronic brake on the Z axis, 6450mm usable long axis, 300x300x300mm (not sure about Z) usable area on the mill. Oh yeah, it weights in at over 5 tones.
Has AC servo drive for spindle, DC servo drives for all axis.
Besides the Mesa boards, i added over 30 or 40 small relays on all outputs, should be in the pictures somewhere on the back side of the control box, used the existing drives and motors and encoders (thanks to PCW making custom firmware for me), existing e-stop loop <== this is very important not to mess with or rewire, etc etc.
-
In general, this is a very hard and very complicated job even for people with experience, so take it easy, read a lot, then read again and again, and when you think you can not figure anything = take two to three days of, go out for a coffee, chase some cats in the yard, throw some stones in the river, or whatever helps you relax, then when you start again = everything starts to fall in place and make sense and seem much, much easier.

the methodology of using a measured cutter verse probing the tool setter pad with the probe is to avoid probing a moving object which can cause a misread of the actual touch probes trigger height. because no two probes will have the same exact spring rate to trigger the chance of inconsistency or a false touch probe tool length offset is much higher then if probing a solid object. granted this variance would be very small so depending on what kind of machine results tolerance you are hoping to achieve it may be within your use case.

the XOR component would allow for using the touch probe to touch off on the tool setter, it is simply using the component to gate the two discrete probe trigger signals into linuxcnc's single probe input. there are some considerations. if the touch probe is NC and is not mounted connected to the machine full time, ie.. it is plugged in or removed depending on if it is being used or not. this causes a bit of strife as the open signal when it is removed puts the probe input in a triggered state. so if this is the scenario you are using you will need to use a dummy plug to simulate the probes closed circuit at the jack. I have seen some jacks that have the ability to close upon removal of the male plug, they are used for power/charging jacks to divert the power circuit back to the battery when the plug is removed. I think I added a diagram some time ago for this in a post but when/where escapes me.

if the tool setter and touch probe both use a normally closed circuit the single input can be run in series so long as if one is removed the circuit is closed artificially.

XOR can also be used in that scenario, just depends on how you want to configure the system. there should be a stock component specifically for probing to make it easy or a prewritten hal example somewhere in the docs as this question comes up far too often not too.. if you guys come up with a working hal example or examples, we can sticky it here for PB users or other general searches to help folks get it sorted out easily.

Rotary machines for round tube are easy, just set them as normal 3 axis machine and make separate configs for each diameter, and use normal 2.5D CAM.
Square tubing is much harder to do properly.
And, i have built machine with attached rotary, almost always concluded that separate machines are better. You can not use both parts of the machine at the same time.

Yaroslav wrote:

This is a random error. I have many other files that are not working. At the moment I am solving the problem by moving them to the root of the machine configuration folder.
 

I have the same problem.
Created about 10 macros and all worked fine.
I edited some of the macros and changed names, all of a sudden the message "File not open" shown when I try to run the macro.
Verified 10 times to be sure file name, MACRO = in ini-file, first and last line (before M2) has correct name.
The macros not edited still work, but the macros I changed the names donot.

@Yaroslav: did you find a solution?

What does
ip a
in a terminal return?
The ping times look way to short (except the 10ms one) so you might be pinging your PC
Then again, i read above that it communicates with the Mesa board, so might be OK, just making sure.

This is incorrect:

setp hm2_[MESA](BOARD).0.pwmgen.00.offset-mode 0 # offset mode so 50% = 0

Offset mode must be set true on the 7I97/7I97T:

setp hm2_[MESA](BOARD).0.pwmgen.00.offset-mode 1 # offset mode so 50% = 0

This is incorrect as well:

setp hm2_[MESA](BOARD).0.pwmgen.00.output-type 2 #PWM pin0

PWM mode must be set for type 1 (PWM+DIR):

setp hm2_[MESA](BOARD).0.pwmgen.00.output-type 1 #PWM pin0

 

@Arciera,

The only motivation in the abstract is to align the normal n with the positive z axis direction.
The equatations for the math are already there.

- Added clothoid interpolation
- Added dynamic plot size

 

@Fabian,
looks like you are making good progress.
Yes. To be honest. I did not know we could do this at all. My math level is not that good.
The progress is fenominal. We now have at least a working solution.

We can now refine, polish code and add different solvers to the codebase. Arciera is hard
working to try out new non-linear solvers, wich are kind off trickie to set up.

The result is a G3 solution between previous and next gcode segment.
Indeed, it matches curvature.

Later on we can test more graphical in opencascade. Wich has also a great codebase
to do forward & inverse transformations.

And maybe, maybe i will code a bi-clothoid in the future. As a 4-clothoid can cause overfitting,
wich is inherent to higher degree curves.

forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77

EDIT:
Did not see the reply from PCW.
Thank you PCW.

The ping test shows the issue with nearly 10 ms delays some times.

If you have a Realtek Ethernet interface it may require replacing
the stock driver with the DKMS one.

You can usually determine the Ethernet MAC on the PC with:

lspci  | grep -i ether

 

Here's an analog tuning tutorial for the 7I77 but applies to the 7I97T as well:

forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77

To start with you need to increase the following error limits so you can see whats going on.
You may not even have the feedback in the correct direction, but with a 0.001 ferror limit
before tuning you will always get a instant following error for any motion command.

Hi guys,

looks like you are making good progress. Short question regarding the single_clothoid_fit() are you only fitting the start and endpoint or are you also trying to match the curvature etc.?