Advanced Search

Use the built in graphics, no add on cards, those usually make latency worse, especially NVIDIA.
Really old Matrox cards were good and had no impact on latency.

I am stuck with latency issue. My system uses MESA through ethernet.

I have Gigabyte H310 S2 2.0 motherboard + Intel i3 6100T (2core) processor+8GB RAM.

This machine when tested earlier without a graphics card had showed Max jitter around 50,000~80,000ns. Then I had added a Radeon(AMD) 2 GB graphics card which clutched latency values within ~30,000 ns.

Now, while testing with actual control panel after complete wiring, the graphics card malfunctioned (temp above 60 Degree C plus monitor black out) and resulted a 49ms latency spike. After removal of graphics card latency returned back to 80,000~115,000ns.

Now, if I conclude that graphics card really helps managing latency, am I doing wrong or right?

Another query, in LCNC documentation, it is written "Graphics card capable of at least 1024x768 resolution, which is not using the NVidia or ATI fglrx proprietary drivers". Now what does that mean? In india, most graphics card uses NVIDIA brand name on packing, not sure about the driver though. Can those be used?

As an example of the basic connections for  channel 0:

7I97T                    Drive
AOUT0 TB3.4        V-REF CN3.1
GND     TB3.3       GND    CN3.16
ENA0+ TB3.2       S-ON   CN3.7
ENA0-   TB3.1       24V    GND

QA0      TB1.1       PA0   CN3.10
/QA0     TB1.2       /PA0   CN3.11
QB0      TB1.4       PB0    CN3.12
/QB0     TB1.5       /PB0   CN3.13
IDX0     TB1.7       PC0    CN3.14
/IDX0    TB1.8       /PC0   CN3.15
 

 

Here is the .nc file I am trying to execute.

tommylight wrote:

Position mode = step/ dir or same as a simple stepper system
Speed mode = velocity mode = analog input of +-10V <<< notice + and -
Torque mode = avoid using this, it requires doing stuff
-
For use with Mesa 7i96S the best would be using the position mode.
Notice of the above notice about + and - , Mesa 7i96S has an analog output that does 0-10V, that is not the same as +-10V.
0-10V on Mesa will work with +-10V drive, only in one direction, so check the manual if the drive has also an input that can change direction.
 

Excellent
I will take into consideration

many thanks

 

Position mode = step/ dir or same as a simple stepper system
Speed mode = velocity mode = analog input of +-10V <<< notice + and -
Torque mode = avoid using this, it requires doing stuff
-
For use with Mesa 7i96S the best would be using the position mode.
Notice of the above notice about + and - , Mesa 7i96S has an analog output that does 0-10V, that is not the same as +-10V.
0-10V on Mesa will work with +-10V drive, only in one direction, so check the manual if the drive has also an input that can change direction.

If you post your modified file I will give it a try.

tommylight wrote:

 

But, does the servo use step/dir or analog input?
 

Unfortunately I have no manual. I searched the internet and could not find a picture of the same. When I posted this thread I thought, ac servo are equipped with both step/dir and analog. Now I will have to find the manual from Aliexpress or try to map the db25 before I can proceed.

The manuals that I found over the net maybe very close to what I have indicate that it has analog signals. It has three control modes, position, speed and torque.

Many thanks

Philip

You mean halui.spidle.0.stop This is an input pin & does totally the opposite of what I'm after.
This will stop the spindle all together.
The halui pins think the spindle is still spinning even when the qtdragon.spindle-inhibit is active

From the QTDragon doc page...
If using the Spindle lift option, HALUI can not be used to pause/resume the program.

I think there needs to be a way to restart the sequence using a qtdragon HAL pin.
I'm not sure if there is one though.

Just in case I have attached the appropriate files.
​​​​​​​
Thanks
Alex

PhilipME wrote:

should I configure the servo motor as a spindle and configure the encoder as spindle encoder

This.
But, does the servo use step/dir or analog input?
If analog, then the above is correct.
If step/dir, then a bit of editing the hal and ini should be done as i do not think the wizards can do that, although it's been a while since i used the wizards, so that might have changed.

similar Problem here, runnig Debian since years never hat a problem till now.
Cannot update
Last Update on september 1st did work
need solution

First off - that was some great investigate work on this problem. That code is very complicated.

I see the problem you describe (even in master) and your proposed fix does seem to work.
I'll have to dig in a bit more to confirm nothing else will break.
Thank you for the report!

Chris

Y-axis:
3:1 reduction is fairly easy to do.  Motors can be flipped around so the output shaft points outboard, with the motor housing inboard using an off-set bracket that puts the motor behind the gantry.  Add a larger pulley to the drive pinion and you'll have an intermediate belt between the motor and the drive system. 

X-axis:
Not so easy as you don't have room on the gantry to 'flip' the motor around like on the Y above.  I'd suggest changing to a ballscrew for the X-axis for a couple reasons:

• Stiffer than a belt
  • Even with a no-backlash belt system, there is still compliance in the belt as the teeth flex.  Belts work rather well for plasma's and lasers, but the cutting forces on a router/mill will expose the problems with belt tooth compliance.  You can't eliminate this, just minimize it with larger belt profiles, wider belts, and more teeth engaged with the various pulleys.
• Doesn't distort the gantry
  • Tensioning the X-belt will/does bend the gantry and perhaps contributes to linear guide friction inconsistencies.
  • A ballscrew won't distort the gantry
• Easy to achieve the mechanical reduction.  A 16mm dia, 10mm pitch ballscrew is fairly inexpensive.  Probably less than (or close to) the cost of additional pulleys and belts, and the 10mm pitch means your motors won't be at some screaming RPM as with a 5mm pitch.

Or... just put ballscrews on all three joints.  No gearboxes needed, no pulleys, vastly improved stiffness, backlash easily managed.

And yes, you'll probably run in to the PS voltage ceiling one you get some mechanical advantage and need more RPM.

M4MazakUser wrote:

Geuss there's no way to get polar coordinates working on the x/c axis.

The way to do it is by switching kinematics on the fly using switchkins.  But LCNC has no 'built-in' polar interpolation or an example in the sims.

I'm aware of two working configurations; there may be more buried in some obscure forum post or github page.

First is from user NoJo.
forum.linuxcnc.org/10-advanced-configura...oling?start=0#225787
I started playing around with incorporating his configuration in my XZC lathe earlier this year, but I've been sidetracked and don't have anything concrete.  I seem to recall a problem (for the rest of us) with NoJo's kinematic module is that he hard-coded a tool offset in the component rather than using a parameter or value based on tool table data plus X-axis position.  It's a little hazy now.

The second is more recent, and is from Franco (@fsabbatini).
forum.linuxcnc.org/show-your-stuff/53476...rical-mapping#307444
This is for cylindrical mapping - i.e. tool oriented radially as with cross-drilling - but I suspect it could be edited for axial live tools and polar interpolation.  I have not looked closely at Franco's scheme - as usual I get sidetracked off projects.

When I finish my mill in the next few weeks (months) I'll be getting back to my lathe project and polar interp will be near the top of the to-do list.  If you get something working (or not) please post up.  I will do the same when I get back to it and make some progress.

If we (and a few other users who have chimed in in the past year or so) can create a very universal kinematics module, we might be able to get it incorporated in to LCNC mainline code.  There are a few lathe-related features which seem to be a recurring "how do I" forum topic that nonetheless aren't on any developer's list of things to add to mainline LCNC:

• C-axis/spindle management (one or two motors, one or two encoders)
  • I know this one is fiddly as it's extremely dependent on the user's actual hardware choices
• Rotary axis look-ahead
• Spindle homing
• Polar interpolation
• Cylindrical interpolation
• GUI handling of multiple tool orientations
• Automatic backplot adjustments triggered by any of the above