Advanced Search

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.
 

Hallo ich möchte gerne ein 5/2 Wege Magnetventil  an eine  Mesa 7i76e anschliessen.
Ich habe folgendes in meine Hal-Datei geschrieben:
net werkzeug-auf <=motion.tool-release
net werkzeug-auf => hm2_7i76e.0.5.output -00
Vedrahtung: TB5 Ausgang 00(Mesa TB5 pin 16)

Linuxcnc meldet  unbekannt  motion.tool-release
 wo ist mein Fehler

mfg 
Hilton

 

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.[/quote]

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.

Hi tuxcnc
I tried increasing the dirhold (PULSE=10, DIR=25) but it still didn't return to the origin correctly. When using a stepper motor, I pay attention to the Sequence Chart of Control Signals. If I use a Leadshine DM542 uses HCPL-063L/15MB high-speed optocouplers for both the DIR and Pulse inputs, so there are no problems using it.
Because increasing the dirHOLD time should have solved the problem, but it didn't. If Riocore hadn't fixed the DIR issue with the cheap DM542 driver mentioned earlier, I could only replace the pc817 with a 6N137. However, I still really hope that Meister will pay attention to this problem.
 
 
 
 
 

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.

rubes wrote:

Am I the only one using QtDragon? 
 

No. You are only one using your config.

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.

Yup, you were right.

I would've thought that since it is a bipolar signal that getting the two wires swapped would just have the effect reversing the sign of the signal. Guess not.

Anyway, it looks like the outputs still work, so massive kudos to PCW for building the card rugged enough to survive a few mistakes.

If I replace the DIR PC817 optocoupler with a high-speed 6N137, it can correctly return to the zero position.   
However, using grbl and mesa 7i92 does not require modifying the DIR pc817.
I may need to use a logic analyzer to observe the timing diagrams of the Tang Nano 9k output pulses and DIR
I'm from Taipei, Taiwan, and my English isn't very good.

 

From what I see in your video, the connection is like this: PUL+ and DIR+ are not connected.
 

My DM542 input pins are connected like this. I've used this DM542 driver on approximately 1000 units. I've used it on Linuxcnc LPT, Mesa 7i92, and Grbl 1.1 controllers without encountering any positioning error issues.