Advanced Search

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.
 

Hi,

My team is trying to use Probe Basic for some milling functions.  We would LOVE to be able to set transparency effects on different STL files in the MACHINE_PARTS file/variable.  We'd ALSO like to be able to show the models, and the mill paths behind them.  Is this possible?  Whats the best way to do this with the smallest code change possible?

Thanks,

Dan

The polarity is wrong, from the looks of it.
-
And since you asked, no it is not Mesa 7i97T's fault but now it might be, as pulling 80mA from it's outputs can't be healthy.
The max. analog inputs usually draw is 20mA, hence the 4-20mA written on them very often.

Hello all,

I am in the process of retrofitting a Milltronics BR50 bridge mill.  The drives are Panasonic Sigma SGDB analog servo drives.

I am using a 7i97T for drive control and a 7i84U for additional i/o.

The problem I am having is that the analog outputs on the 7i97T don't seem to be putting out enough voltage when connected to the Panasonic drives. When nothing is connected to the 7i97T, a multimeter on the analog outputs reads the expected +/- 10V when set via HAL. However, with the drives connected, the voltage drops to almost 0.

If I put the multimeter in series with the analog output, set to output 10V, to measure current the voltage drops to a fraction of a volt and the current reading on the meter shows about 80mA. One of the little green LEDs on the 7i97T also dims slightly.

The weird thing is that if I use a 3V coin cell connected to the drive's analog in with the same meter in series, the current only measures at 0.1mA. Also, measuring the impedance/resistance of the drive's analog input shows a resistance of around 37kOhms. This is using the same wires as used by the 7i97T, so I don't think it is a wiring fault. 

I don't think it's a HAL problem since the expected voltages can be output via HAL to the disconnected board, and I don't think it's the drive or wiring since the tiny coil-cell battery works.  I'll attach my work-in-progess HAL/INI files below.

Is it possible that the problem lies in the 7i97T? The problem occurs on all the analog outputs and with all three servo drives.

 

5280 wrote:

the 2 lines of code do nothing but take me back to the prompt.


 

Sorry, I can't figure out how it can return nothing. It should display the status of lightdm. And if lightdm does for some reason not exist, it should complain.

Does it work when you try those two commands after you're logged in and run startx?

What make/model laptop is this? Some laptops do not run linuxcnc correctly.
 

just FYI, I moved this configuration off the RPI-4 onto a new computer (fresh installation from the released ISO) and still get the same. Figures I would be the only one to have this "issue". Am I the only one using QtDragon? cant be, as it is a very cool GUI.