Advanced Search

unknown wrote:

I probably when OTT with power supplies.
What I did was use some light weight DPDT relays, one set of contacts latches the relay after briefly being energised by a pushbutton and the other set of contacts controls a contactor with a 24v coil. I find this a great because if the power is removed, blackout breaker tripping, and comes back on the power doesn't come back on.
I went with a relay > contactor setup as I wanted to keep the 240 seperated from the 24v control. The only issue is that there is an always on 24v supply dedicated to the relays.
To clarify there's one relay/contactor per power supply. Each power supply can be independently controlled. For wiring the latching relay I had some PCBs made to simplify the wiring.
Bit more involved than a 4 way gang switch. The same thing could be implemented with a NVR switch for each PSU.
Oh I forgot I'm series with each pushbutton is another switch, this is used to turn the relay off and has to be in the "on" position before pushing the button to turn the power supply on. It's kind of like starting a rocket.
 

Hi Rob,

Thank you very much for your explanations. The first solution is way over my head

I am going to study the NVR switch. They look better than 4-gang switches and more accessible, too.

Best regards,

...behai.


 

Thank you @tommylight and @unknown ( Rob ),

I appreciate your suggestions. I have learned of this set up from this YouTube video from the thehardwareguy channel.



Please see from 5:40 to 07:50 -- he uses a 2-gang switch, even though he has 2 PSU and 1 VFD.

Best regards,

...behai.

 

This has gone a bit sideways, hence my restraint to delete it, so vote?
Me voting:
all the same!

On the main to the left of the DRO axis labels - the group of buttons
 

25:1
20:1 or 30:1 as i fully agree with Rod and Snowwy, it gives a better working range, although it will be very hard to actually see any difference in normal use, but might be noticeable at very high feed rates as it would track better the surface of the material. Never actually tried to notice as no plans for it, it works and it works very good.

Found it


forum.linuxcnc.org/show-your-stuff/30648-rugbot-1000

If i understand correctly the "MDI queue", i se no reason for it, ever.
It is a simple as manually editing a file and open/run it in LinuxCNC, and i do this a lot.
Once opened, LinuxCNC has also the option to edit it from the file menu, removes the need for looking for it on the drive. LinuxCNC can also edit any opened file, granted the correct text processor is set in the ini file.

thanks, It's work perfectly now

As I also stated on github, I really like the MDI queue, but I understand why some may not want it. Please make it configurable. I would even say that the old queue behavior should be the default, and if someone is making machines to sell, they can put a line into the ini file to remove the queue. No need to take it away from me, I used it a lot... until a few days ago when I upgraded... to find out that someone decided for me that I should not have it!

That would probably require modifying the PlasmaC component code as it is built in:
github.com/LinuxCNC/linuxcnc/blob/master...ponents/plasmac.comp

I mean this where is in qtdragon_hd gui
linuxcnc.org/docs/html/gui/qtdragon.html#_touch_plate

EDIT: I double checked and it seems you received my email. I removed your email from my post. I will type out a small part of my email here for other people in the community who might find it useful in the future.


Part of email:

Importantly, I have an external encoder that is already attached to the lathe headstock, so I DO NOT need to use the encoder on the servo driver, infact, I already have the encoder set up correctly to my mesa board. In a future project I may use the servo encoder but i suspect my drive does not actually have encoder output setup as the manual says not all versions come standard, and i have no connector (although it must be somewhere inside haha)


Using your files, here is the progress I have done:

1. I have went through and integrated my machine parameters into your hal and ini, halcompiled the caxis and gn-userkins, and added the remapped gcodes
2. The software does boot up successfully but doesnt fully work: X and Z move and work fine. The encoder works and outputs the live C value

What does not work - something that has failed me in many other attemps

1. The C or spindle do not work, the first issue from debugging is homing - it seems homing does not work. I am going to try and disable homing or try a workaround
2. I suspect after homing is fixed, I will get some additional vague command line errors. Likely from my lack of coding experience and improper linuxcnc logic, but not certain.
3. There are a few other annoying issues I suspect, but I do not want to get ahead of myself.


I will also upload my current HAL and INI which are the only files of your I have changed. Is there any chance I could get your input on the HAL and INI and if you have any obvious suggestions I may be missing?

unknown wrote:

For the sunix cards that use parport_serial you need to look here for the list of devices.
github.com/torvalds/linux/blob/master/dr...ort/parport_serial.c

But notice that the driver code used is different depending on kernel version. As I linked to before here.
linux-hardware.org/?id=pci:1fd4-1999-1fd4-0100

Use this page to search by PCI ID to see what drivers match what card.
linux-hardware.org/?view=search

Driver matching & Loading (binding)
docs.kernel.org/driver-api/driver-model/binding.html

Wow! Thank you very much!

Model: Unitek Y-7507 ( 1245 / KFD-4VO / KFD-4V0 / E162585 / 94v-O / 94v-0 )
Chipset: Moschip MCS9901CV-CC
Interface: PCIe
Modes: PCSPP, TRISTATE, EPP
Supports X Mode: NO (Control register pins are not open collector)

A detailed report is attached.




 

If I received it, please delete the email address. I have another question: Do you have feedback from the servo motor encoder connected?