Advanced Search

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

I've installed everything.

Also:
sudo apt update
sudo apt --fix-broken install
sudo apt install python3-qtpyvcp
sudo apt install python3-probe-basic

cd ~
mkdir dev
cd dev
git clone github.com/Lcvette/qtpyvcp-bookworm-installer.git
cd qtpyvcp-bookworm-installer
./install_for_qtpyvcp.sh
./updater.sh

And yet I still get this error:

Traceback (most recent call last):
File "/usr/bin/probe_basic", line 8, in <module>
sys.exit(main())
^^^^^^
File "/usr/lib/python3/dist-packages/probe_basic/__init__.py", line 20, in main
qtpyvcp.run_vcp(opts, VCP_CONFIG_FILE)
File "/usr/lib/python3/dist-packages/qtpyvcp/__init__.py", line 26, in run_vcp
run(*args, **kwargs)
File "/usr/lib/python3/dist-packages/qtpyvcp/app/__init__.py", line 129, in run
launch_application(opts, config)
File "/usr/lib/python3/dist-packages/qtpyvcp/app/launcher.py", line 78, in launch_application
loadWindows(config)
File "/usr/lib/python3/dist-packages/qtpyvcp/app/launcher.py", line 230, in loadWindows
window = _initialize_object_from_dict(window_dict)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/qtpyvcp/app/launcher.py", line 210, in _initialize_object_from_dict
return obj(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/probe_basic/probe_basic.py", line 53, in __init__
self.load_user_tabs()
File "/usr/lib/python3/dist-packages/probe_basic/probe_basic.py", line 87, in load_user_tabs
user_tab_folders = os.listdir(user_tabs_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Error 2] File or directory not found: 'user_tabs/ # REQUIRED Setting for Probe Basic'


Where is the 'user_tabs/' folder supposed to be? I've moved it to:
linux/configs and, just to be on the safe side, to linux/configs/My_Machine

Try this: