Advanced Search

It's the same screen. Jim's original name was silverdragon. When I incorporated it into linuxcnc, I renamed it in the code. We just got used to calling it qtdragon so in 2.9 I went with it.

Jim also has a newer version in github.

notJamesLee wrote:

Friends,

from what I can only assume is inconsistencies in diameter or something but 533.33 is the number.

with 533 after 20+ revolutions you can see the starting point creep earlier -- indicating its just short of the number of steps to complete a full circle.

with 534 after 20+ it goes the opposite way.

I have a few follow up questions:

- what should i have the dip switches set to? Now that we've figured out they don't do anything to effect the steps per revolution is there an optimal value for this? I dont need insane amounts of torque or rpms

- is this something i can easily fix with the encoder once i do move to LCNC and tune in the encoder error?

thanks all for sanity checking me thus far, nice to know im not 100% crazy.

Sounds like you're still struggling with the driver, yes?

Maybe I missed it, but what brand/model driver do you have?  Asking because some drivers can be tuned via software (in addition to dip switches), and there may be a setting (or another dip) that disables the external dip switches.

No need to apologize, war is hell.

If I see it correctly it has a LPT port?
There are different version I see now. So it has 7 input pins (GPI) and 7 output pins (GPO).
With a XYZ machine you'll have just enough output pins to control the steppers, but like PCW said you'll need to create a driver for it.
If you could still return it, the one with a LPT port might be a better choice. If you want to be more sure that it will work reliable with a fast rate a hardware controller will be a better choice.

Fair enough. Perhaps when it’s ready for prime time, we can work through the other issues to come up with a cohesive solution and find a way to push the project as a whole forward.

I prefer to be positively realistic

Keep up the nice work!

Yes you should switch. At least try it.

yes but they are not answering

Control cabinet almost finished. I just need to install 20 push buttons and connect them to the usb matrix board. I will mount a new keyboard with a trackball also.

theslawek wrote:

1. Should I expect M5 to stop all spindles, or do I have to get used to using M5 $-1?
   • Is it possible to get M4 to work? It doesn't do anything right now.

M5 - I recall some discussion on Github about what should be the default behavior for multi-spindle M5 commands.  I found a commit that appears to change M5 to 'stop all spindles', and any of the $ modifiers are for individual spindles.
github.com/LinuxCNC/linuxcnc/commit/01a0...d65486193ead51027c29

Probably want to do some testing yourself.

M4: I think what's going on is that step/dir spindles require an explicit reverse speed value in the INI file, despite what the manual indicates.
linuxcnc.org/docs/devel/html/config/ini-...:ini:sec:spindle-num

adding
[SPINDLE_1]
MAX_REVERSE_VELOCITY = 550

Might do the trick.

If this doesn't work, the next thing is for you to get used to using the 'halshow' feature in LCNC.  This is a simple but powerful tool for debugging since it lets you see what LCNC is doing behind the scenes.  In your case, you want to know why M4 isn't working so you should display all the HAL pins which affect the spindle - including the PID pins.

When you open halshow there's a folder tree on the left where you can click on all the pins (real physical pins, or logical pins) in LCNC.  Once you select those they will appear on the right in the 'watchlist'.  On/off (bit) pins will look sort of like red/yellow LED's, and other pin types will display the value.
What you want is to display all the pins which form the internal logic chain that starts with and M4 command and ends with the mesa stepgen outputting signals to the drive.  Figuring out all the pins and how they're logically interconnected is not always straightforward... but it also didn't cost you buckets of money.

This is where coming to terms with HAL is necessary:

All this stuff like this below still makes no sense to me as to what its purpose is.
net spindle1-vel-cmd-rps        <=  spindle.1.speed-out-rps

'spindle.1.speed-out-rps' is a logical (not physical) pin inside LCNC.  When LCNC starts up and reads the HAL file, there are a number of default functions that are automatically loaded. One of these functions is called 'motion.comp', and a description of what it does and all the related pins which are created is located here:
linuxcnc.org/docs/devel/html/man/man9/motion.9.html

If you read through that page, what you find is a list of logical pins which are created when LCNC starts.  Once those pins are created, you can do 'stuff' with them by connecting them together.  I won't go in to specifics right this minute, but any pin which is connected to spindle.1.speed-out-rps will receive a value that is equal to the commanded rotary-axis spindle speed in revolutions per second.

Hopefully this will click with you soon.

BUT

Assuming you didn't mess things up significantly during your editing, I think there may (still) be at least one bug in Mesact or PNCconf for step/dir spindles.

See where spindle.1.on is connected to hm2_7i76e.0.stepgen.04.enable through signal spindle1-enable?

This connection will result in the stepgen shutting off instantly when the spindle is turned off - no controlled deceleration.  This result in a massive BANG! when the motor drive stops dead, and can lead to over-voltage trips in the drive or broken things.

This should have been fixed in LCNC 2.9, but it appears to still be an issue:
github.com/LinuxCNC/linuxcnc/issues/2748

This bug shouldn't affect M4/reverse not working, but I bet your spindle stops HARD right now and doesn't decel gracefully.  

Have you contacted the manufacturer yet ?

Spent some time chasing the mysterious Z-0.511 value.
The value pops up at Homing.
Cleared linuxcnc.var and linuxcnc.var.backup without joy.
Went through all the setup files, until I got to tool.tbl - and there it was, the cutting length of tool T1 = 0.511.
Launched Gm, selected the tool editor, and T1 was 0.511, and ticked as selected.
Cleared the tick and closed/opened Gm - but the 0.511 comes back, with T1 selected in the tool table !!

Found a youtube clip by sliptronic that includes a view of his tool table.
T1 is selected and set to length 0.00.
It could be the default behaviour of Gm is to automatically load T1, then allow for its length in the displayed position.
Edited my tool table to make T1 cut length 0.000.
Now Gm loads with only the minor offset errors (0.008 etc).

Honestly I have no idea how to do this so is there a guide or documentation that i could follow because from what i read the pc might have an embedded controller for the gpios that is why when i run gpiodetect on the terminal nothing shows any help would be appreciated.

At first not, but in fact, it help.
I thought there was a way to have all slots listed automatically from the handler file. In fact, the slots are listed once we add them manually as described in this help page.

I've encountered your problem recently. This clearing is usually caused by your lack of proficiency in using the VI editor. When you exit, the file saving action is not completed!!

@SnowGoer540,

At the moment we have 2 testers who failed to run scurve on their machines. One off the testers
is running the cia402 with ethercat. Somehow linuxcnc has following errors using the tpmod_scurve.
At the moment we are unable to find the reason. Maybe kernel is too slow, mabye it's something else.

The other tester is anonymous and problably has multiple machines running. He pointed out the latency is very bad for
the latest debian 13 rt kernel. So i made a debian 10 and a 4.19 rt kernel wich he is familair with. But this also runs dramatic
on my laptop.

Then on my laptop i got also poor results using ethercat steppers at the moment.
In the past everything worked flawless, but this was on a normal desktop pc running ethercat and steppers.
Therefore maybe the problem is just the laptop, performing poor on the rt kernel.

Then there is the cmake build system wich i use to compile the scurve planner. The linuxcnc makefile is unable to
compile c++ code along with it. And i think the cmake build system for the scurve planner will not be merged to the linuxcnc
github source, because it doesn't align with the current makefile system.

Then there is that extra licence note, that will not be approved, but still has our attention.

So even when the scurve run's nice in a linuxcnc simulator config. There are still other problems that has to be resolved at the moment.
Therefore i think it's too early to do a git push request.

Personally i don't see linuxcnc as a fractured project. Best is too stay positive