BeagleY-AI, DM542T, and Linear Actuation

Use as your discretion...

You will need to apply 5v and 3.3v for use with the 74HC126 and DM542T with a conversion needed.

Also:

The reason the above ISSUES have arisen is because of my lack of understanding. This is not an issue, per se, from any of the mentioned components (drivers and SBC) but I would take precaution when altering wiring around these components (drivers mostly).

Hey There,

I have been working on making some 3.3v CMOS logic NOT-GATES/Hex Inverters work alongside some motor drivers (DM542T from omc-stepperonline.com).

The build is far from perfect and it is currently a work in progress (WIP).

The reason I state, "The build is far from perfect, " is that the motor heat still gets elevated, i.e. even though I am using resistors alongside the hex inverter called the SN74HC04N from Texas Instruments.

I am using a BeagleY-AI board for GPIO peripheral usage.

The BeagleY-AI is from beagleboard.org and they promote Open Source initiatives and Open Source Builds for their boards and other ideas in electronics and education.

Anyway, here are a few photos to show exactly what is going on...

I have some linear actuator, motor driver, and I am using the hex inverter to push over 4mA per GPIO pin off the peripheral.

The motor driver calls for about 7mA to 16mA while the hex inverter can push up to 20mA or 50mA through GND and Vcc continuously.

I do not have a video just yet. I broke my end stop for security and need to figure out the logic in the source code a bit better.

Off to figure out if the inverter should be used in this type of application, e.g. of course not. But, it still does some work towards making the motor application accessible.

Here, I found some nifty videos I made on the build in question. Ask away if you need any additional data...

Outside of Hex Inverters pushing continuous amperage

• First I tried a https://www.ti.com/product/SN74HC126/part-details/SN74HC126N type chip
• It is a buffer with OE (output enable) pins
• The gates perform positive logic
• Here is the datasheet in .html format: https://www.ti.com/document-viewer/SN74HC126/datasheet
• So, there are three states of logic: (1) HIGH (2) LOW (3) HIGH IMPEDANCE
• HIGH and LOW of the I/O can be measured with an oscilloscope and/or testing other references like voltage across channels
• Impedance is usually AC and needs to be measured with a LCR meter or very accurate testing done with a few other test equipment types
• But! In our example, CMOS is direct current from the BeagleY-AI and to the SN74HC126 and a safe bet would be to measure all outputs (+/- 70 mA) of our buffer gates which is our total in the package to use continuously (mA)
• So, at around 70 mA is when our SN74HC126 may fail
• Luckily, we are pushing 4mA roughly per pin from the BeagleY-AI to the Input of the SN74HC126
• Also, the OE pins are all on GND pins
• So, no floating should take place but there is still an issue

The tests so far read back as output on the console. This output is shared as ns amounts of print statements in Python3.

Latency maybe but I think maybe my I/O is incorrect and I am the one that should know exactly what I have done.

So, until then, more testing will ensue!

As I have been testing some end stop/switch logic. I came across a neat-little set of source code stating that with a NC and COM pin set on an end stop should work with this set of source code:

As you can tell from the AI generated source code, our short ns reply on output should show nano seconds of data on the console.

I am not so sure our source code is correct just yet. More attempts on the way.

So, it seems that there is a complication that I did not see right away. The tri-state outputs of the 4 Output Buffer (SN74HC126) are not all connected as the datasheet shows.

So, this is our connection...

In the Manual/Datasheet for the DM542T:

There is a common-anode and common-cathode set of connections that can be made...

In this build, I used the common-cathode connection.

So:

SBC:        74HC126:                 Logic Level Converter:              DM542T:
GPIO1       1A to 1Y      Left Side 3.3v GPIO to Right Side 5v GPIO     PUL/STEP +
GPIO2       2A to 2Y      Left Side 3.3v GPIO to Right Side 5v GPIO       DIR +
3.3v          Vcc                         Left Side                        
5v            Vdd                         Right Side                      EN +/-
GND           GND             Left Side GND and Right Side GND            EN +/-

The reason for EN +/- being listed twice here and labeled as GND only is that more
testing is needed to handle this contraption.

So, think of this post as a test if you are not 100% familiar with the BeagleY-AI,
74HC126, logic level converter, and the DM542T.

That will make the source code run in Python3 and all while using the limit switch and a GPIO Pin as Input and oh. The limit switch, by way of understanding from beagleboard.org, can be directly attached to GPIO and PWR-Vcc-3.3v.

So, one pin of the limit switch goes to a GPIO pin while the other pin goes to 3.3v in our case. So, if we have a NC (Normally Closed) tab and a COM (GND) tab on our limit switch only, we can set up NC and COM to make a circuit on our BeagleY-AI. It is always smart to try to use resistors in rotation for I/O on the BeagleY-AI.

So, like our highlighted common-cathode set up above, between SBC (the BeagleY-AI) and 74HC126 1A and 2A, respectively, we would place a resistor (4.7k or 10k) so that if we encounter some higher than mA current, the GPIO pin and/or processor will not exactly become "toast."

So, from out SBC to input of the 74HC126, a 4.7k resistor would suffice while testing.

Now, we need to configure the two GPIO Pins as Output so that the Input Pin is in the mix which will attempt to switch the Outputs On and Off when needed. More to come...

That is the update for now. I finally got the correct wiring done for the tri-state driver called the SN74HC126.

It seems that placing a resistor in between the 3.3v supply and our GND while our other grounded pins are going to the Output Enable pins, the outputs listen to the commanded Python3 source code.

So, clicking the limit switch entails some logic on the source code side of things.

Once the limit switch is clicked, the RPM of the motor switches its turn to negative 800 steps while when the limit switch is not pressed.

Update

Okay, so I think I may have some positive logic analyzing and 74HC126 chip usage answers now:

• So, everything works and this is the good news.
• The bad news is that it took me way too long to handle the positive logic in the 74HC126.
• So and anyway, all works. Good news, right? Well, there is even better news.
• The motor in question stays slightly cool even in sweeping motions during the moves it makes on the linear ball screw.

The above set up will handle STEP and DIR on your wiring side and testing on the breadboard is a bit more complicated than just "throwing" a 0.1uF capacitor at it but you can review the documentation/datasheet of the 74HC126 to find out about the mathematics of the capacitor...

I will post another video to show a couple .py scripts and .html files to handle an online server for adjusting parameters on your linear ball screw from a stepper motor.

• Now:
• The motor is staying cool with a Pololu logic level converter...
• The commands, for the most part of the script logic, are commanding like never before today and doing well at it.
• Luckily, I got some good lessons out of the entire shabang and I am going to keep with it. When there is an issue, find out about it, learn from it, and then succeed with notes, reporting, and summarize.
• Done for now! A little confusing for now but I will keep at it to make better sense...

https://www.faulhaber.com/fileadmin/Import/Media/AN001_EN.pdf is the .pdf to learn from currently if you have an extra 25 minutes.