Advanced Search

I've tried to run NativeCAM with qtdragon after a couple of changes:

# required NativeCAM item:
EMBED_TAB_NAME = NativeCAM
EMBED_TAB_LOCATION = tabWidget_utilities
EMBED_TAB_COMMAND = gladevcp -x {XID} -U --catalog=mill /usr/share/linuxcnc/gladevcp/NativeCAM/ncam.ui

And I copied an existing folder in qt_dragon config folder.

The NativeCam tab (empty) is shown, but NativeCAM wont'run cause it declares a DISPLAY problem.
I'll try to trick NativeCAM to avoid the display check, to see if it will run.

Regards
Giovanni

Hi!
Is it possible to home a machine only using the scales and no other limit switches? Have found a bunch of posts regarding this, but none gave me enough clarity. In one i think Andypugh did some testing/developing to get this to work?

/Hampus 

You will most probably get stuttering if you do not also set the P value to 500 for each joint/axis in the ini file.
Those two are strictly related for normal stepper systems, for 1 million servo period the P value is 1000, for 2 million servo period the P value is 500, for half million servo period the P value is 2000, and so on.
And i am pretty sure Mesa controllers do not use buffers for the motion control in the normal sense of "mach3" boards, might use for IO, but i never checked, after over 10 years of using Mesa boards (probably over 80 by now) and never ever having a single issue with them, and most are on industrial machines in use 10 hours a day every day (never turn off, though), and having tailor made firmware to my needs, and having the best support on Earth, i absolutely stopped worrying about it.

I meant to add:

But I'm more than happy with your answer!

Okay. I wasn't sure whether it could cause stuttering of some sort, if the commands to the Mesa weren't sent in time.

My naive mental image is that the Mesa service routine is called from the servo thread, and it sends multiple commands like "Step X +25 times and Y +10 times" during each call. And I assume the Mesa maintains a queue of such commands, and the servo thread needs to run often enough for that queue to never become empty prematurely.

So the answer might involve knowing how big a buffer the Mesa has for that queue, and whether the minimum execution time for a bunch of very quick commands in that queue is shorter than the servo period.

I do not think you have to worry about it, it just updates everything 500 times per second instead of the usual 1000 times per second. Probably changes nothing in the step generation part as it's done on the Mesa, but might raise the time to halt the machine from 1ms theoretically (practically 2-3ms) to 2ms theoretically (guessing 4 to 6ms), and since those are still way to short time intervals, i do not think there is a situation where one would save the machine and the other would break it.
Either way reaction time of normal mortals is in the half second to a full second range, minus the Formula 1 drivers, those must be gifted with some fast reflexes, otherwise the Formula 1 would be a race to who crashes last, not 2 hours of extreme stress, be if physical or mental.

If you installed linuxcnc as RIP,  before running qtpyvcp execute the following command at the prompt:
source ~/your rip path/linuxcnc/scripts/rip-environment 
Note you don't need to run linuxcnc just source its environment this allows qtpyvcp to find what it needs  to run

I didn't fully understand it, but I've already tested your update, everything works fine.

 

That would work.. I pushed something similar before your post.

I wonder, is there a Raspberry HAT that can direct interface with a stepper driver ?

Thanks
Jonh.

I'm using a Raspberry Pi 4 to drive a Mesa 7i96.   For unknown (as yet) reasons, I can't reliably run without errors unless I bump SERVO_PERIOD to 2000000 (i.e., 2ms).

What affect will this have on machine operation?  I sort of understand what's scheduled to run in the base thread, which of course is largely (completely?) irrelevant now that I have the Mesa.  But I don't have a good mental model for what runs in the servo thread, so I don't have a good understanding of what happens to operation/performance if it only runs half as often as usual.  Where would the difference show up?

Until recently my mill maxed out at about 40ipm, so absolute performance wasn't really a consideration.  I've upgraded to a machine capable of at least 80ipm using Grbl, and initial tests with LinuxCNC and the Mesa card indicate 100ipm may be fine.  So now I'm wondering if I need to start worrying more about that servo thread.

paul

Yes, it seems like some encoder option is not set correctly.
Clearing the count on every index really makes no sense for
general encoder use.

I don't really know but it seems to be set in the ini file:

 

It works. Thank you.

Thanks, PCW for this example! I try this out the next days. 
or2 is not used actually. 3D is NO and WZL is NC, otherwise I would have put them both in series.
I will see if I have to delete the -not for the 3D switch.
Thanks a lot and have a nice weekend!
Hanno