Advanced Search

So it was a busy week, but here is the list of keys that I modified to get the spindle running.  Some of the values are specific to the spindle itself.  My spindle is 2.2kw air cooled, so my max rpm is 24000 and the minimum rpm is 12000.  also my pwm range is from about 5v to around 9.6, so i adjusted the values is the 5 section to make my max voltage equal 24000 rpm. the values in the parenthesis are the values that i used, but will vary depending on your spindle

P00.01 - 1
P00.03 - [MAX OUTPUT FREQUENCY] (400)
P00.04 - [MAX RUNNING FREQUENCY] (400)
P00.05 - [MIN RUNNING FREQUENCY] (200)
P00.06 - 2 [ANALOG INPUT 2]
P00.07 - 1
P00.10 - 60 
P00.11 - 6 (seconds to accelerate)
P00.12 - 6 (seconds to decelerate)
P00.14 - 4.0 (2.2 KW)

P02.01 - [MOTOR RATED POWER] (2.2)
P02.02 - [MOTOR FREQUENCY] (400)
P02.03  - [MAX RPM] (24000)
P02.04 - [MOTOR VOLTAGE] (220)
P03.05 - [MOTOR RATED AMPS] (6)

with this section, anything under 5v will also give me 50% power, so the spindle can never run less than 12k rpm.  just to be on the safe side, i also set the AI2 settings to the same values (37-40)
P05.32 - 5.00
P05.33 - 50.00
P05.34 - 9.6
P05.35 - 100.0
P05.37 - 5.00
P05.38 - 50.00
P05.39 - 9.6
P05.40 - 100.0

This allows me to use the stop key to override the spindle in case of emergency
P07.04 - 3 
 

Thanks for the help. It wasnt in the accessories submenu. So I did a full reinstall and now it works perfectly fine. Just gotta learn how to set it all up. Thanks a lot for the help

What do you mean by: "had no 10V output for spindle supply from the beginning"

Isn't the VFD itself the spindle supply?

Apologies for not responding sooner. Yes, I would like to be able to set my tool length offsets by lowering Z until the dial on the analog gauge reads 0 and register that position in the tool offsets. Like in Axis this would be the point where one would, as I understand it, press Touch Z in the gui, but there is no Touch Z button in QtDragon. Now I would of suspected that there might be some alternatively named button or a line of some mystical gcode that could be entered that would write the offset into the tool table, but after looking for days, I have found nothing that would explain how this could be done.

I know all my problems would be solved by just getting an electronic tool setter, but at the same time I am baffled by there being no example, or set of instructions that I could find, as to how to do the tool length offsets by hand and analog gauges. It's all push the button stuff and nothing I could find that helps someone understand what to do if there is no button to push.

Is there a specific reason why QtDragon does not have any plugin, addon, macro, or screen that would facilitate manual tool setting?

Please post specific model and link to datasheet.

I thought USB was generally considered bad (for latency, speed, performance, etc.)

Ok I got the key to work and 2.10 instaled by doing this in the terminal:

sudo wget -0 /etc/apt/trusted.gpg.d/buildbot-archive-key.gpg *http://buildbot2.highlab.com/*  (without the *)

sudo apt update

sudo apt upgrade

I did this after adding the new repository in the sympathetic package manger.

Unfourtanetly this did not fix my issues. When I dry run the gcode previously posted my feed still does not slow down to 20%, it stays at the base feed rate. So Im guessing I have to link something in hal now? any help on this would be great as I havent worked with hal before.

Also, now on 2.10 when I try to edit gcode with the edit button in qtplasmac it does not load the gcode back into qtplasmac after "saving" and doesnt save the gcode at all. So, I have to edit it in a notepad instead. Im guessing this is just a glitch with 2.10 and will be fixed.

I once tried to communicate with an Arduino over USB.

Anything below 9600 baud was 100% broken.

Not sure why.

9600 baud is the lowest you should use IMO.

The 5.2V is not really an issue as you can scale (and bound) the analog output
so you get 0 to 5V at 0 to full RPM.

 

My e-stop switch has 2 actual switches:
One sends E-stop signal to LinuxCNC, the other one mechanically prevents any signal power from reaching the SSR that controls the router.

mesambccc compiles the modbus device(s) specific xml source file
to data files that hm2_modbus uses.

Typical mesambcc usage would be something like:

mesambccc  -o ~/linuxcnc/configs/mb25ioc32.mbccb mb25ioc32.mbccs

Where mb25ioc32.mbccs is the xml source file and mb25ioc32.mbccb is the resulting
data file that the driver uses. 

Hal file setup is described in the hm2_modbus manual page:

man hm2_modbus

A minimal 25IOC32 xml source file looks like this:

<mesamodbus baudrate="9600" parity="N" interval="1000" >
 <devices>
  <device name="mb25ioc32" address="0x01"/>
 </devices>
 <commands>
  <command device="mb25ioc32" address="0x0000" function="R_INPUTS" name="input" count="32" />
  <command device="mb25ioc32" address="0x0000" function="W_COILS" name="output" count="32" resend="true" />
 </commands>
</mesamodbus>



 

Because I use a control panel with all my machines, I utilize many halui signals for program start/stop, spindle start/stop, overrides, etc.

I would try to avoid using halui and use the pins created by gmoccapy and use a hal structure to only enable them when auto mode is on.

 

www.linuxcnc.org/docs/html//gui/gmoccapy.html#_hal_pins

 

Hello,

I ran a test again—maybe it will help someone solve the problem.
The system configuration is as follows:

Debian 12
LinuxCNC 2.10.0-pre0
Gmoccapy 3.5
Configuration generated with Stepgen (basic 3-axis mill).

Because I use a control panel with all my machines, I utilize many halui signals for program start/stop, spindle start/stop, overrides, etc.
As you can see in the video, the spindle signals (halui.spindle.0.is-on, spindle.0.forward/reverse) work correctly when the program is started by clicking the Start/Stop buttons in the Gmoccapy interface, and the number of lines in ngc file is fewer than ~1100.

However, when I load longer files than 1100 lines (attached a test file) and use halui.program.start/stop signals, the spindle signals behave differently and cause the spindle motor to restart from the HAL program.
I believe the issue is related to halui.program.stop. For example, if I start the program using the Gmoccapy button and then stop it using halui.program.stop, the problem still occurs.
But if I start the program using halui.program.start and stop it using the Gmoccapy Stop button, the problem does not occur.

Interestingly, the issue disappears when I reduce the number of lines in the program to below approximately 1100 lines (the test .ngc file originally had around 12,000 lines).

As shown in the video, the spindle signals reset at program stop and—though not every time, in about 8 out of 10 cases—they are set again shortly afterward and remain true.
When using only Gmoccapy buttons, the signals reset, generate a short pulse a bit later, and then reset again.
If the .ngc file contains fewer than ~1100 lines, the spindle signals reset at program stop and do not set again—no pulse is generated either.

Files and video:
drive.google.com/drive/folders/1MjqY3XpM...5T-rd4Og?usp=sharing


 

pgf wrote:

Gave the new axis-like UI a spin this morning. Looks and feels good. I noticed the buttons (e-stop and machine-on, in particular) don't have the 3D "I'm pushed" look when they're pushed released. A small thing, but there's no other visual way to tell the state.

I need to come up to speed on modifying these UIs, so I can make changes and flesh it out. (I know, I know... watch the videos. ) The big missing piece for me right now is a probing/touch-off screen. My current probing setup is pyvcp, so clearly it will need to be redone. But I'll bet you already have fully functional probe screens just waiting to be dropped in.
 

The Touch Probe 3 example has full working probe routines that you can drag and drop onto your gui.


JT

Did some work on the toolbar toolbuttons...



JT

Have a look.
As I said I use a M2 realtek nic on top. Isolcpus=1 works for me, but it depends on the build in cpu. So you have to test. Also be aware to make the lines in the network interface for the intel nic. Other than that, as one can see the m710q can run a read time of 200k ticks @ nearly 3GHz. And the jitter is quite good for eth mesa cards.