Advanced Search

Hi All so i have a question
so how do i know if my Ethercat install is successful, I check the Master is active the Slaves are there
I now need to do the HAL files and config xml 
i have this not sure if it is correct
i have 6 servo motors , 

Looking at the drawing, it seems to be missing 1 degree of freedom. Is this intentional? Or am I overlooking something?

No big deal as the guy that sold me my first computer said "a computer is pure MAGIC"

the laptop is a Dell Inspiron 5737, 43GTQzi, Bios A07 started out it's life with Windows 8 on it

I'll re type the command lines and again and see what comes up. but not right away

tks again for the help.! I keep trying

Sorry for my poor English – enjoy it; it’s the first and probably the last video in which I’ll try to speak English.

www.youtube.com/shorts/u9xUOXN080M

Well, yes, blue is a 3.3V level, as I measured it directly at the FPGA pin

No promises.

tuxcnc wrote:

viewsat wrote:

If I replace the DIR PC817 optocoupler with a high-speed 6N137, it can correctly return to the zero position. 

This is wrong way.
By modifying the driver, you risk damaging it and reducing its reliability.
Although the PC817 has a very low bandwidth, the correct solution is to increase the dirhold.

Tux, you have a nasty way of replying, and you have been warned once about it.
It is their choice if they want to modify something or not, that is what DIY is about and helps with learning.
You are right about PC817, but you are wrong about dirhold as it does not magically raise the level to 5V on 3.3V systems.
I understand you are trying to help, so thank you, but the way you do it sometimes comes as very offensive and demeaning.

It's more likely the bogus message comes from hal_glib library watching the limits switches without knowing about shared homing use.

There is no such pin. Please always read the documents. type: man motion

Aciera wrote:

I think this is actually a bug in the QtDragon GUI.

Moved to the Qtvcp section so maybe @cmorley picks it up.

If it is, its a new one, I had no problems with a single home/limit switcch. Feel free to review my hal and ini files
github.com/rodw-au/vmnmillqt/tree/main

saxa wrote:

What you exactly mean by "downdraft zones" ? I have not yet build the table where the workpiece will sit on.
But the gantry is already existing and here are some pictures of when I received it.


 

Some large commercial tables have a central exhaust duct down the side or up the centre and as the torch passes into a zone, a gate opens and the others close (usually by pneumatics) so the draft is centralised in that particular cutting zone. It is possible to track the torch position and activate the relevant zone with LinuxCNC. The dust is usually filtered and the exchaust ducted outside of the building. I did write a component that did this for another user which triggered a bank of air solenoids.

Hello everyone,
I'm working on a robot. There are some errors, and I want to verify the DH parameters to be sure. What should the axis placements and DH parameters of the robot, whose drawing is below, be?

I'm using Genserkins.

Tommy can you see if this works for you if you get time I want to get a few 2nd opinions and make sure most people can get this to work.

Hey tux once I'm finished I can make you a special version if you want with no special tool stuff. I'm integrating my machines with a lot of extra features that provide the other stuff that you need for production CNC machines like part counter and lots of other stuff.

The dream here is just too give back to linuxcnc a bit. I'm not going to bend over backwards to change things for people am making this for me. But I also am happy to accommodate other workflows where I can. Also I never use gmocappy and probably won't want to put the effort into testing on that too..

Also are you testing on the newest config I made. I just tested that again. And using axis fanuc sim. the .ngc file loads automatically. I'm using 2.10 linuxcnc debian iso. (I actually have never managed to replicate your bug but try this latest one please and see if you can find it. Also I been running parts on the production lathe all week and fixing a couple of bugs I found plus new features. This will probably get refined over the next few months and I'll keep adding updates here when I get time.

Dear Mr @hakan, I want to get your mail address if possible,
mine is This email address is being protected from spambots. You need JavaScript enabled to view it.

meister wrote:

viewsat wrote:

meister wrote:

All my positive terminals are connected to the purple cable via a thin wire.

Dirhold isn’t the problem; it really is the voltage that’s coming through – there was a clear difference between 3.3V and 5V.

My connections are like in your image, but with EN connected.

You could use a multimeter to check what voltage is coming through your DIR pin.
 
I suspect that when the DIR signal starts acting, it might not follow the set dirhold wait time, outputting PULSE before the process is complete. When encountering a motor driver with a slow dirhold response, this results in an invalid PULSE output. It's strange that increasing the dirhold value doesn't solve the problem; this is a problem I don't understand.
 




You can check that Dirhold is working using Testbench and by monitoring it on an oscilloscope or logic analyser.
It worked for me with the default settings, but it’s certainly better to set it to the manufacturer’s specifications to be on the safe side.


(cd riocore/plugins/stepdir/ ; make)

In my tests, the problem only occurred at 3.3V;
if you Google ‘DM542 problem’, you’ll find lots of reports of the same issue.

I apologize for asking so many questions. I always use 5V to power the 74HC245 and the driver. If there's a problem, usually adjusting the DirHold time is all that's needed. When I use a Mesa 7i92 + 74HC245 (5V) + DM542 (pulse=10, DirHold=25), everything works perfectly, and it correctly returns to the zero position. However, when I switch to a Tang Nano 9k+ + Riocore + 74HC245 (5V) + DM542 (pulse=10, DirHold=25), it fails to return to the zero position, and adjusting the DirHold time doesn't help.