Advanced Search

forum.linuxcnc.org/49-basic-configuratio...-lube-time-component
github.com/AlexmagToast/LinuxCNC-LubeDude

How’s it going.  So I recently switched over to GMOCCAPY from the traditional Axis interface.  I have to say it looks much nicer and I like how tool touchoff and setting g54 home positions is much more intuitive.  In Axis I always made the mistake of not selecting the correct joint when doing touchoff and accidentally set my tool length offset as a X or Y offset shift then go crash the machine during a run.  Anyways besides all that, I’m now wanting to go to the next level and start customizing the GMOCCAPY interface.  I want to start out with something simple like a machine running timer alert.  This would be an alert that tells me to oil the ways after 10hrs of runtime.  This way the oiling is perfect and scheduled saving on way oil.  Stuffs not cheap lol What I’m trying to make happen is a function that’s tied to the run button that then activates a timer and stores the time running in a file on the hard drive.  When the total time running = 10hrs reset the time and display a message saying: “The machine has been running for 10hrs now.  It is time to Oil the ways.”  Where should I start on this?  I know there’s a hal.program-is-run and a time.N.start.  Then what do I do?  time.N.start <= hal.program-is-run?  Sorry I’ve never programed python much but have some C#, Java, VB, SQL, C++,and XLM skills.  My collage sucked and never let us program in Python.

Or using "voltage dividers" made from 2 resistors for each input also works fine, but care must be taken to prevent the lower side resistor from disconnecting.
It does induce more current draw from outputs though, but i know for sure in most cases all is OK.

Oh yes, i did disagree with that statement, silently, as he might have experience with "Home" or "Office" types of HP computers and those are frankly cr@p, but "Enterprise" HP computers and workstations are magnificent in every way and some have 700W or 1000W power supplies despite no way of cramming stuff in it to require that kind of power. Same goes for Dell and Lenovo and Fujitsu and older Fujitsu-Siemens, all of those in the "Enterprise" edition work perfectly, no matter how old, and using them 24/7 is a given.
And yes, there are many of us here using HP even on industrial machines, as again, they never fail.

Usually connecting +Z or -Z from encoder to Z input should work fine.
Also, depending on + or - you get active low or active high.
Might have issues with "open collector" type outputs from encoder, can be easily fixed with a resistor between +V encoder power and input/encoder output.

not sure what you are referring too with G43, it changes here but you must have a tool called with it to set the offset. no tool in the spindle will give no g43. here with tool in the spindle g43 works as expected and can swap back and forth between G43 and G49 and it shows as expected in the machine status column on the right side.

as for the probe question, im not sure what you are meaning? all probing in probe basic is predicated on using a wired probe or tool setter that can sent a signal to linuxcnc letting it know a probe move and event have occurred and been recorded.

can you elaborate on both above topics so i can better test and answer?

That's what I thought, the problem is that many drivers have differential feedback encoder outputs and I would have to use another IC to convert +Z - Z to Z.

unknown wrote:

... it aggravates me when I see opto circuits with the input and output sides connected to a common ground.

+1

langdons wrote:

A really big relay should not need arc suppression.

Please do some research before making such statements, especially after it has been answered by a VERY experienced member of this forum.
And who asked about MosFET's ?

I'm pretty sure Tommy would disagree with that, personally I've never had any issues with HP gear, even the ancient server I was running 24/7.
I'd say that there are quite a few HP machines running Linuxcnc that never give any issues.

Yeah, a manual MPG shouldn't require reading at the same rate as would be required for spindle encoder.
Just remember that the RPi io is only 3.3v tolerant, so a way of translating the MPG signal voltage and protecting the RPi io from noise.
The 74lvc series are 3.3v devices that are 5v tolerant on their inputs.

so your saying take the Pi GPIO and put it on a server thread not on a realtime thread?

Some do some don't, you'll need to check the data sheets.
The role of the diode is to protect the driving circuit from the reverse voltage generated from the collapse of the magnetic coil. No flyback will eventually cause component failure, a far bigger issue than EMI.
I'd take PCW's advice.
Another thing I would look at is the routing of your wiring and ensuring physical seperation of control and AC, if you haven't already taken care of this issue.
If you do use optos make sure that the input side and output side are powered by seperate PSUs and the ground are not connected, it aggravates me when I see opto circuits with the input and output sides connected to a common ground.

The issue here is that the relays are switching a 120VAC solenoid.

Because the solenoid is an inductive load, this will cause massive EMI unless
there is contact arc suppression across the relay contacts. This can be done
with a bipolar TVS diode, a MOV or an RC arc suppressor.

Flyback diodes might increase contact arcing becuase they slow down the release of relay contacts.