Advanced Search

This topic came up nearly 2 years ago when I started to look at the STM32H7.

forum.linuxcnc.org/18-computer/42276-rem...spi?start=590#252207

Something that we'll need address at some point and some learning curve as Mbed does make things simple to have a code base for multiple targets. The use of submodules was suggested but I never really got deep into understanding how we could re-structure things. 

Thanks! that has fixed it

slowpoke wrote:

Well thanks to spumco for providing this link...
spumco post=294853 userid=28776

github.com/AlexmagToast/LinuxCNC_ArduinoConnector

I now have a little nano board communicating with HAL both inputs and outputs. So I just need to port the communication code from the nano test board into my ARM project and rejig the messages a bit and with a touch of luck I should have bidirectional data flow from HAL to my board. Hopefully the .py script is easy on the Linux overhead.
 

ArduinoConnector has major issues that the author does not seem to want to fix as they've been working on a V2 branch. The last commit was my friend fixing a bug I found before I dropped it. I wasted alot of time with ArduinoConnector, I made 2 custom PCBs around it just to realize it had so much lag it was unuseable (see my git issue).

Maybe version 2 will be better, but the main branch can't handle an MPG. You will wait literally 10 seconds for it to count the pulses and relay them back to LinuxCNC. All the lag comes from the Python side, the MCU side is fine. It's a great idea, with some great features. Unfortunately it's currently unusable unless you just want to push a couple of buttons.

Thank you ,I've read the doc of screen_options in qtvcp widgets.I think it may be exactly what I want ,but the doc is lack of more sample code of usage ,so it's not very easy for me to use it .Not like the other qtvcp widget such as ActionButton,very easily to use.the screen_options seems to require more background knowlege ,would you show some sample use of this widget ? I'll be very appreciateful of that .

If they are anything like the ones i had, and they sure do look and sound so, they have ABC not ABZ signals, all are incremental outputs, but not linear at all, the rate changes depending on motor angle.
Open hal scope and monitor all 3 pairs, use something to consistently turn the motor, slowly, see the width of each line change at a certain point.
I really hope they are not the same, as those are useless for anything except Yaskawa drives.

Problem came back! Something updated, possibly Debian, and now my screen is too wide again. See attached photo. What's different is that I can't set it to Start as Windowed and then back to Start as Fullscreen to fix the problem. Also, the modification to Gmoccapy by alex_sar earlier in this thread does not work anymore, although it did for 6+ months.

My touchscreen monitor is set for native resolution, 1024 x 768

I have the latest version of Debian Bookworm.

I thought that updating everything might help, so I updated LinuxCNC from 2.92 to 2.93 and Gmoccapy from 3.4.6 to 3.4.8. No joy.

Help me newbynobi , you're my only hope!

    I recently had a terrible time trying to implement an older (90's) Yaskawa servo motor with "incremental" encoder UTOP1. It would run rough in one direction and smooth in the other with an AMC brushless drive and 7i77. I opened the encoder cover and found odd looking tracks (see 1st and 3rd encoder band on picture). I'm curious on the purpose of it? It's clearly not a standard incremental evenly spaced grating. The additional 3 sections that repeat 4x I assume are the commutation hall signals and the inner 2 are the index. Maybe open yours and see if the tracks are odd looking?  

i left this machine sit here for a few hours turned on and now this is my output of ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 66:98:11:36:d9:48 brd ff:ff:ff:ff:ff:ff permaddr 9c:2a:70:32:72:49

where did my wired networks go?

well so much for that solid state relay. the one I got only seems to work as an on/off switch and doesn't
have any in between. We will see if the below will work better. At least they are designed from the start
for PWM.

www.amazon.com/gp/product/B07C7RQ4C6/ref...00_s00?ie=UTF8&psc=1

I vaguely remember seeing that one
The documentation I looked at had C=index
(and S = serial absolute position)
but that must be a different model

If that's the case, you will likely need
to use plain q mode (magnetic alignment)
rather than QI mode

A long time ago I tinkered with some Yaskawa drives and motor/encoders. What I THINK they do is change the phase between the A-B and C channels to indicate what quadrant the motor is in, and that allows them to detect the proper commutation to use to move from that position. So, the A and B are perfectly standard quadrature, but the C channel has transitions at the same rate as the A or B channel, but the phase gives additional information.
Jon

You really need to measure _across_ the pairs
to validate the wiring

Who says that I will fight you guys

but your pretty quick, cap

Its not dead for another 2 years, but I actually started replacing mbed a few weeks ago for other reasons.

Makes no difference though, the core is pretty much the same across the remoras. Only the rpi spi one uses mbed anyways. It could be made to work with stm lib on PIO

github.com/cakeslob/Remora/tree/mbed-ce

github.com/cakeslob/remora-mbed-ce
this is the repo I plan to work out of because its cleaner

github.com/mbed-ce/mbed-os/discussions/306

I just have to figure out this cmake business first

@aciera,  thank you very much!  - do you have experience with non-trivial kinematics?  The example in the document you sent is actually pretty close to what I'm trying to do with a few exceptions. I note that the forward and inverse transformations transform joint lengths (AB, BD) to Cartesian coordinates.  if the joints were cables wrapped around a drum, would it still be appropriate to transform cable length the cartesian coordinates or would you actually resolve that back to stepper motor steps in order to define a cable length?

 

Actually I had checked with multimeter - ALL pairs had 3,3V on one and 0,5V on the other wire. and vice versa when HalShow reported that the pin value has changed.
I googled for rs 422 voltage levels and this picture came up:
advcloudfiles.advantech.com/cms/2fde048f...ge-1540322331041.jpg

According to last line everything is correct at the moment, so I do not even understand where to start to look for miswire - all the pairs behave the same.
Am I missing something and is that picture wrong?