Advanced Search

Hello,

I am currently trying to get the toolchanger working with probe basic. It works however the subroutine (m13) is made for a continuous motor. This machine uses a stepper motor, with a custom stepper driver. If I enable one relay it moves the carousel one pocket. The relay needs to deactivate before it can be repeated. There is another relay to change the direction. I was wondering for the homing of the carrousel, is there a good way of doing this?
Like a while loop which activates the relay, waits a little bit and deactivates it until the home sensor is activated?
 

Switches wear out over time and require less force to actuate, which can make a slight difference, bearings wear down a bit, screws loosen slightly, etc.

That's what I mean by mechanical changes.

By mechanical shifting I mean like a leadscrew no longer being in exactly the same place after years of operation due to slight movement of stuff over time.

SIDE NOTE:
My grandparents recently bought a house that was built in 1974 and were told it would not shift or settle because it was built long ago and has had time to settle for 50 years.
But vibrations caused by renovations caused the walls in the basement to crack a bit visually (structurally, it's all fine).

You could use a 7I96S spindle configuration as an example.

Depending on what source you read Australia has anywhere from 10 out 15 fifteen to 20 out of 25 of the most deadliest snakes. As Rod said almost all aren't that aggressive and would rather be left alone.
I can testify to that, my Beagle tracked one for about 10 minutes, effing Brown of all things, and all the poor bastard wanted to do was get away. Bloody dog has a thing about snakes, most beagles like rabbits and the like, but my weirdo dog tracks snakes....gotta be really on the ball when walking him near areas with bush.
A other funny thing about Oz, we have the largest population of wild camels....reckon in the next 25 or so generations they'll get poisonous like every thing else.
Actually it's not that bad, it's only really the coastal areas of Australia where people live, maybe 200k in and after that it's pretty sparse.
Just need a bit of common sense, don't annoy the wildlife, careful which plants you touch and don't go on the other side of the railing to get a closer look at the Blow Hole.
Oh and don't argue with the Highway Patrol, they're the guys the Outlaw MC gangs rejected for being too anti social and morally corrupt.

ok thanks jt, soon as i get to the shop i will check the pins.

btw, do you have some boilerplate code for a pwm spindle? if not i will dig in my archives and see if i can get the old spindle code working

Thanks for the answer. Is there no way to operate my machine like this?
One option would be to swap the X and Y axes, but is there another option?

For Mesa step generation (others are similar) LinuxCNC creates a local feedback loop
where at every servo thread invocation, LinuxCNC reads the current stepgen position
and then sets a new velocity based on the current commanded velocity and with a small
correction based on the current position error. That is, at every servo thread invocation,
LinuxCNC generates a new position. Based on that new position and the current stepgen position
a new velocity is calculated to meet that new position at the next servo thread invocation.

With Mesa hardware the precision of the control loop is 1/65536s of a step, so typically
the error between the commanded position and the stepgen position is never more than
a fraction of a step.

Here is a plot of stepgen error at:

10 ms servo thread
1 IPS cutting speed
5 IPS rapid
50 IPS/S accelration

Note that Velocity is in IPS  per division and error is in 20 uinch  (~0.5 u) per division

The residual noise in the error is caused by timing uncertainty in the position sampling.
This is about 2 usec at a 10 ms servo thread but about 400 ns at a 2 ms servo thread

 

Even the chord error is nothing to worry about as long as you do not have extreme
acceleration (say > 1G)

 

This is how the interface looks like.
 
The difference, the contrast in style is obvious.
So I think with a QT interface, as you are doing, it would be better.

Giovanni

Yes it's a lot of work but it will be all QT.
You have to change at least all the interface.
That's a very good job.

"My" (note the quotes, cause it's not mine) version, the solution I proposed in the message above it's only the "standard" gtk-tkinter version for python3 in which I disabled the exit to sys if the screen is not axis, gmocappy... etc. allowing to be used with qt_dragon interface.
The empty Ncam tab is only to launch NativeCAM with LinuxCNC.
It's meant to be only a temporary solution if someone really need to run it.

Regards
Giovanni

I just released version 1.2.1 of Flex GUI which includes Axis style controls and an example of Axis style GUI using Flex GUI.

JT

I tested it. (Updated dialog_widget.py and macro_widget.py)
It works fine, but only with the "load" button. If I want to save the settings, it's the old way. (path from qtdragon.pref)

I think it would be better to always use the path defined in the macro file. Then each macro can collect its different settings in a defined directory.

If it's a lot of work I wouldn't bother. Either I will finish the qt version or adapt your version.
Qt version seems to mostly work, but looks slightly different:

 

 

Does the sample basic spacer work for you?
Also the turners cubes I can't get to work (flat verse diameter error)

Chris

PCW wrote:

With Mesa hardware (and most external hardware step/dir interfaces
or even EtherCAT drives), the velocity (step rate in this case) is updated
every servo thread.

This means that there is a constant velocity between updates. This constant
velocity means that that you will  have a small error (chord error) between a
desired curved path and the actual (linear interpolated) path.
 

Okay, that's interesting, and of course I have more questions.

First, does the Mesa know how many steps it should count?  Will the longer period introduce greater error in the length of each chord?  I.e.,  might it overshoot by 1ms worth of steps, vs. just 500ns worth of steps?   Or is the command to the Mesa really just "start moving at N steps/second"? (rather than "start moving at N steps/second, for 10500 steps")

Second, the chord error you describe would only occur for a curved path.  If the G-code is written completely using straight-line approximation (which of course introduces its own chord errors), it seems like the longer servo period wouldn't introduce any more error at all.  True?

In any case, it sounds like I can stop worrying about my 2ms servo period for the time being.

paul

For a 7i96 spindle you have to add that manually at this point. Now that the 7i96 is back in stock I might work on adding a spindle to it in MesaCT.

Watch the output pins as you toggle flood and mist in the halshow program.

JT

macrotab will now honour these entries in MACEOOPTIONS:
default:default.txt
path:~/linuxcnc/nc_files/macros

You can set them to any valid name.path you like (filename must end in .txt)

Do you think it would be nicer to use this path the very first time then use one from the preference file? This would make it remember the last used path rather then always using the one defined in the macro file.