Advanced Search

Glad to hear you're up & running.

Cheers
Rob

Brilliant!  I just had GMNOCCAPY up and running for hours without a glitch after making that change.  Believe you nailed it.

Thanks for the great tip.

Jeff

Thanks scotta , ini and hal attached.
I played around with the p i d settings today in the INI but it made no difference. Dip in voltage was still there. Also when I set the gain to 0.0025 which should be the correct value for 4000rpm. It doesn't scale right. I need to input 0.02 for it to work.
 

What makes me wonder is why  constantly forcing index-enable low does not cause a problem for you.
 
You are right. I haven't used G33.1 yet. Will test it soon. 
But from the looks of it, this is not easily solveable --> need to disconnect the index somehow...

EDIT: Could we write a switch component that passes the signal in both directions (similar to mux2 but bidirectional... ) ?

EDIT2: The easiest solution for this is to probably just install a optical sensor as a second index signal... and then use this for indexing in M19 or for G33.1 ?

Thank you. I was clearly fantasizing that the mesa card would give me the power of linuxcnc and the ease of deployment of grbl. Silly me.

For the spindle 0-10v output there is a PWM to analogue chip on the board. Remora uses hardware PWM to drive that chip. The 0 - 100% SP determines the duty cycle for the PWM.

It would help to share your config files to see what influences the SP on the LinuxCNC side as there is no interactions between the Remora modules, stepgen and PWM, running on the EC500.

forums.linuxmint.com/viewtopic.php?t=371688
forum.chuwi.com/t/linux-successful-scree...ts-via-scripts/15385

langdons wrote:

Newer versions are not always better.

 

I agree with you. I have several computers running for different tasks (Debian, Ubuntu, OSX, Windows). I work in IT. I just want to test whether I can possibly benefit from version 2.9.4. If it doesn't work, I'll continue to use version 2.8.4.

Running axis if that matters.

I just flipped my Lenovo Yoga upside down to put the screen at a better viewing angle. Initially the display was upside down, that was easy to correct with Settings | Display | Invert.  So display is now correct

However the touch aspects is still inverted, (touching lower left, shows touch at upper right). How do I go about inverting the touch aspect?

Thanks in advance and much appreciated.
 

Aciera wrote:

Was kann ich von der alten Konfiguration weiter verwenden, was muss ich anpassen und was muss neu erstellt werden?

Um zurück zur Frage zu kommen würde ich wie schon erwähnt mal probeweise die neue Version auf eine zweite festplatte installieren und deine jetzige Konfiguration mal laden dann kann man auch gleich auf konkrete Fehlermeldungen eingehen.
 

Das habe ich auch so gemacht. Ich habe gerade keinen Zugriff auf die Fehlermeldungen. Es gab aber schon Fehler in der INI Datei.  Daher ja auch die Frage. Ich kann morgen nochmal schauen.

Real time kernel is a must for all machines, no matter how it is implemented things need to be done in time.
Yes you need real time kernel for mesa, yes it has to be connected directly to controlling PC (it also works through switches but i would not use for production machines) and absolutely not on a shared network due to switch latency when loaded, and latency is not so strict as for parallel port when using mesa, even 200000 latency can be usable.
Parallel port = software step generation on the PC
Mesa boards = hardware step generation on the board

Thanks!

I guess I'm a little confused about the real-time part. Somehow I thought going to a Mesa board would eliminate the need for doing jitter and latency tests and measurements. Sounds like all it's doing is letting me locate the PC some distance from the mill. If the PC still has real-time constraints, are there constraints on the network as well? Can the ethernet be a shared network, or must it be point to point?

pgf wrote:

I have custom code in the servo-thread currently.  (My X/Y axes aren't square, and the code corrects for that.)  Will this continue working, i.e., does that part of motion control remain in linuxcnc, and not in the 7i96?

Yes.

pgf wrote:

Will I still need a real-time kernel?  Can I run linuxcnc from...  anything?  My laptop?

Yes, yes, yes and no, meaning yes you can run a laptop and no as they usually cause issues with latency due to inherent power saving options built into them. You can always try...

pgf wrote:

Will things like surface probing, and probed touch-off, still work, assuming the right configuration of a couple of the 7i96 inputs?

Yes.

pgf wrote:

Anything else I should know about this transition?

Again yes and no, yes it will be new experience and it is fairly easy if you can follow directions, and no you do not need anything else to actually start working on it, it is much easier to learn as you do stuff.

That's cool. I had tried both Gemini and Copilot, and I didn't get anything close to as useful as that. Thank you again.

I'd like to eliminate my dependence on the "mill PC", which is still running Wheezy and some ancient LinuxCNC release.  So I'm considering a 7i96, so I can do things across the network.  But to be sure I'm not blind-sided by some bad assumption, a couple of questions:

I have custom code in the servo-thread currently.  (My X/Y axes aren't square, and the code corrects for that.)  Will this continue working, i.e., does that part of motion control remain in linuxcnc, and not in the 7i96?

Will I still need a real-time kernel?  Can I run linuxcnc from...  anything?  My laptop?

Will things like surface probing, and probed touch-off, still work, assuming the right configuration of a couple of the 7i96 inputs?

Anything else I should know about this transition?

paul