jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #beagle
jfsimon1981_b has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981_c has joined #beagle
jfsimon1981_b has joined #beagle
KevinP has quit [Quit: Client closed]
doppo_ has quit [Ping timeout: 246 seconds]
doppo has joined #beagle
<set_>
RuntimeError: Not a sysfs PWM channel: /sys/class/pwm/pwmchip5/pwm1 <<< This is my error when running the source from yesterday.
<set_>
I tried w/ /dev/bone/pwm/1/b/ too.
<set_>
I think there is something wrong.
mattb0ne has joined #beagle
mattb0ne has quit [Client Quit]
outrageous has quit [Remote host closed the connection]
outrageous has joined #beagle
mattb00ne has quit [Ping timeout: 265 seconds]
Shadyman has joined #beagle
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
<set_>
jitter!
zmatt has quit [Ping timeout: 268 seconds]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 265 seconds]
zmatt has joined #beagle
<jkridner>
k
buzzmarshall has quit [Quit: Konversation terminated!]
doppo has quit [Ping timeout: 248 seconds]
doppo has joined #beagle
<set_>
PRobably a connection issue?
<set_>
Off to test again!
<set_>
but like you say, it could be the bi-directional logic level shifter...
ikarso has joined #beagle
rob_w has joined #beagle
Shadyman has quit [Quit: Leaving.]
johanhenselmans has quit [Quit: johanhenselmans]
florian_kc has joined #beagle
florian__ has joined #beagle
ft has quit [Ping timeout: 248 seconds]
florian__ is now known as florian
florian_kc has quit [Quit: Ex-Chat]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #beagle
<set_>
@zmatt: for whenever you can get to it or reply at all, I was working w/ the BBBW and the source for the PWM and GPIO but my PSU is garbage. So, I need to rekindle another PSU and test then. Heads up!
<set_>
I got the motor to work w/ another Cape but not w/ the connections to the TB6600 for whatever reason.
<set_>
I mean...the motor turns on, flips out on me, and then buzzes constantly w/ battery and/or PSU...
<set_>
So, I cannot tell exactly the issue so far. Probably, the TB6600 is not receiving the signaling well enough b/c of what you said...
<set_>
4mA per pin might not drive the op amp or whatever is in the TB6600.
<set_>
I found another op amp laying around here. I am going to test w/ it soon. It accepts 3.3v logic and can output signals that can then be understood.
<set_>
It could also be that the BBBW does not have an adequate power supply going to it, i.e. no barrel jack connection. I will test this also.
<set_>
I wanted to test w/ the MotorCape but the items specific to that Cape may have to be arranged a bit differently. I will test w/ it soon.
<zmatt>
set_: "Not a sysfs PWM channel: /sys/class/pwm/pwmchip5/pwm1" ... that's clearly a bug in my code
<zmatt>
must be some difference between the kernel you're using and the one I tested on
<zmatt>
set_: can you pastebin the output of: udevadm info /sys/class/pwm/pwmchip5/pwm1
<zmatt>
set_: for now you can just disable the check by commenting out lines 24-25 of my code until I've fixed the test
<set_>
I will soon. I just got called. I am sorry. I have to go. I will test the update when I return and notify you of the udevadm info /sys/class/pwm/pwmchip5/pwm1 command.
<set_>
Please forgive me.
<zmatt>
no rush, I also need to go, but with that output I can probably fix the issue later
<set_>
Thank you. False alarm on my side. No issue about the time...
<set_>
For some reason, everything w/ permissions is root.root.
<zmatt>
set_: no, clearly not everything since if the period/duty_cycle/enable attributes of pwm channels were root:root you wouldn't be able to use them as normal user
<zmatt>
but most things in /sys should be root:root yes
<zmatt>
it's the default unless specifically overridden by an udev rule
florian has quit [Quit: Ex-Chat]
<zmatt>
hmm it does seem that on the stable buster image way too much of /sys is writable by group gpio
<zmatt>
like way way too much
<zmatt>
I wonder if there's some broken udev rule causing this
<zmatt>
yep there is
<zmatt>
ah it's already been fixed by rcn
buzzmarshall has joined #beagle
ft has joined #beagle
<set_>
Hmm.
<set_>
My image is about Feb. of this year old.
<set_>
So, just under a month old.
<set_>
I will install a newer image and hopefully this will cause the "fix" to take place...
<set_>
I update/upgrade.
<set_>
I did revert back to 4.19.x. Busted is how I felt. I quickly erased the 4.19.x kernel and moved back to 5.10.x.
<set_>
The root.root in /dev/bone/pwm/* was evident.
<set_>
At first sight, I saw root.gpio permissions in /dev/bone/pwm but looking into the files at /dev/bone/pwm/* by using ls -l, I quickly saw that everything was root.root.
<set_>
Further down the page, I listed ls -l /dev/bone/pwm && ls -l /dev/bone/pwm/*
<zmatt>
those are the permissions of the symlinks
<set_>
Oh!
<zmatt>
and some parent directories
<set_>
I thought I had to be of the group to use those files?
<zmatt>
no
<set_>
i.e. debian or gpio?
<zmatt>
symlink permissions are irrelevant (which is why they always show as rwxrwxrwx) hence the group is irrelevant
<set_>
Oh.
<set_>
Okay.
<zmatt>
and there's no reason for a normal user to have write-access to directories like /dev/bone/pwm/0
<set_>
But, I need to write to /dev/bone/pwm/1/b/enable?
ft has quit [Remote host closed the connection]
<zmatt>
yes, but that doesn't require write access to /dev/bone/pwm/0
<set_>
or /duty_cycle and etc.
<set_>
Aw.
<zmatt>
write access to /dev/bone/pwm/0 is only needed to create or delete files in that directory
<set_>
Oh!
<set_>
Brb
<zmatt>
but its contents is managed by udev
<set_>
-rw-rw-r-- 1 root gpio 4096 Dec 31 1999 /dev/bone/pwm/1/b/duty_cycle
<set_>
So, can gpio groups be able to read/write to/from this file?
<zmatt>
see that "rw-rw-r--" ? that means the owner of the file (root) can read/write ("rw-"), the group of the file (gpio) can read/write ("rw-"), everybody else can read ("r--")
<set_>
Okay.
<set_>
I am part of the gpio group and if needed root too.
<set_>
I checked.
<zmatt>
user debian shouldn't be part of group root
<zmatt>
only root should be part of group root
<set_>
I have the command groups. It states debian, a bunch others, and then gpio.
<set_>
User debian is not part of the root group/user/uid/whatever.
<set_>
I tried chown debian.gpio /dev/bone/pwm/1/b/*
<set_>
No go. I need sudo or root privileges.
<zmatt>
stop messing with stuff
<set_>
Fine.
<zmatt>
the ownership/permissions are already set correctly
<set_>
Okay. So, okay.
<set_>
I need to reflash an image that is not busted I presume is the answer?
<zmatt>
???
<zmatt>
what are you talking about?
<set_>
Flashing a new image to the BBBW is what I am talking about now.
<zmatt>
yes but why?
<set_>
If things are not working b/c of something I did, I need to restart.
<zmatt>
what's not working?
balrog has quit [Quit: Bye]
<set_>
PWM, GPIO, access, permissions.
<zmatt>
be specific
ft has joined #beagle
<set_>
Okay.
<zmatt>
you reported an issue with my sysfs_pwm (the "Not a PWM channel"), that was a bug in my code when used on kernel 5.10 and it should now be fixed
<zmatt>
you've not reported anything suggesting an issue with permissions or anything that would suggest reflashing
<set_>
When I typed the file command python3 My_File.py, which is supposed to run the inner code,...Oh.
<set_>
I had an issue w/ permission once.
<set_>
I know what you are saying. I will reattempt to set up the hardware and go w/ the newly put forth source.
<zmatt>
see stuff like "I had an issue w/ permission once" is not useful to mention. unless the issue is currently present and you know the exact error and what you were doing that triggered it there's absolutely nothing anyone can do with that information
<set_>
The only issue I have seen w/ that source and not my set up, is "permissions" and "not in sysfs."
<zmatt>
saying "PWM, GPIO, access, permissions" is not working is meaningless, nobody can give feedback on that
<set_>
But, you cured both aspects to the issues at hand.
<set_>
@zmatt: Stop getting so upset. Sheesh.
<set_>
I understand.
<set_>
I am not connected right now.
balrog has joined #beagle
<set_>
The hardware is off the BBBW.
<set_>
I have to rewire that pup and try again and I will.
<set_>
I just wanted to mention that I have come across the error (NOT 0) and once it had to do w/ permissions.
<zmatt>
what error
<set_>
This is what led my down the path of setting up symlink permissions outside of /etc/udev/rules.d/*
<set_>
A catch in your source.
<set_>
It caught permissions erorr :2.
<zmatt>
symlinks do not have permissions, and anything to do with symlinks in /dev/ or permissions of stuff in /sys should be done by udev rules
<set_>
Okay.
<set_>
Fine.
<set_>
Done.
<set_>
No more messing w/ rules and links or unlinking or whatever.
<set_>
If the permission is not granted on my machine when I run the newer source you have provided, I will tell you.
<zmatt>
I know that a while back there were still udev rules missing for some stuff on the testing image you were using, but I helped you fix that so I don't understand why you're suddenly talking about it again
<set_>
Lack of sleep?
<set_>
Maybe.
<set_>
But...I circle back. Silly, yea. I seem to have similar issues that are easily identified.
<zmatt>
you've not reported any permission errors in recent times until you just right now started rambling about it again, my guess would be as a result of me asking for some ls -l output (which was just so I could check how things are organized on 5.10)
<set_>
No sir.
<zmatt>
anyway, afk
<set_>
I promise. Aw!
<set_>
I cannot handle this right now. I am going to jump up and down until I read the Earth's core.
<set_>
read = reach
<set_>
Sheesh.
ikarso has joined #beagle
<set_>
I have a busted PSU, still. This may take longer than expected.
djinni has quit [Quit: Leaving]
djinni has joined #beagle
<zmatt>
set_: keep in mind that nothing substantial has changed in sysfs_pwm in either of the two updates, the first just added some additional checks against misuse and the second update fixed a bug introduced by the first update... the only thing to test would be that the erroneous "Not a PWM channel" error is gone, you don't need anything connected for that
<zmatt>
other than that you're not going to magically get different results than before
<set_>
The LEDs on the driver are on. The motor is excited. No movement yet.
<set_>
I tried something simple to start before embarking on...
<zmatt>
that just sounds like it's hooked up wrong
<set_>
I listened to the damn people. I am thinking they know less of what they are selling...I cannot confirm this sort of rhetorical garbage.
<zmatt>
but yeah the error... I added those checks before I realized that you're (ab)using pwm to drive steppers... what your code is doing can't be done reliably hence my library now gives an error
<set_>
Okay.
<set_>
No issue. I tried.
<zmatt>
also your code makes no sense, the only correct pwm value for driving steppers is 0.5
<set_>
Oh.
<zmatt>
since their speed is controlled by frequency
<zmatt>
but that's not what pwm is designed for
<set_>
I know.
<zmatt>
pwm literally means "pulse _width_ modulation" .. not pulse frequency modulation :P
<set_>
Same w/ fading LEDs.
<set_>
Ha.
<zmatt>
fading leds does use pwm
<set_>
I understand.
<zmatt>
controlling led intensity is exactly what pwm is for
<set_>
@zmatt: Fading a two wire piece called an LED is the same as moving a motor in one direction. Fading the LED backwards is the same as moving the opposite direction in motors.
<zmatt>
?????
<zmatt>
what? no?
<set_>
But the TB6600 says no GND w/ PWR and vice versa. SOme IC and OP AMPs.
<zmatt>
what you're describing is only true if your pwm output is used as position control signal for a servo
<set_>
I get it. Mechanical inertia and magnetism are not digital.
<set_>
I think this is how they made this piece.
<zmatt>
?????
<set_>
The TB6600 seems to use two pwm channels and one GPIO?
<zmatt>
no it doesn't
<set_>
how do you know?
<zmatt>
what are you even using a second pwm channel for?
<set_>
I looked at the diagram.
<set_>
To go.
<set_>
And trust me, it is a diagram.
<zmatt>
it needs a gpio for controlling direction (DIR) and optionally a gpio for disabling (EN)
<set_>
So, no one like me could mess up was the idea.
<set_>
Oh.
<zmatt>
and it has a pulse input (PUL) that's used to step the motor
<set_>
I understand. But, in the diamgram, it shows two PWM channels and one GPIO (presumably a GPIO).
<zmatt>
the pulse frequency on that input is what controls motor speed
<zmatt>
no it doesn't
<set_>
Let me show you.
<set_>
Scroll down and read the fine print on the DFRObot Duino or whatever it is. It shows ~ for PWM and a number. Then for GPIO, it only shows a number.
<zmatt>
set_: that just means the pin *supports* pwm, but they're not using it for pwm
<set_>
Oh...
<zmatt>
in fact it looks like they're using all three pins in gpio mode
<set_>
Okay, concluded.
<zmatt>
since they connected PUL to a non-pwm-capable pin
<set_>
Wait...what?
<set_>
Ha!
<set_>
Dang. I am behind the times.
<set_>
So, I just use GPIO to handle each separate usage?
<set_>
Blah.
<zmatt>
on a small microcontroller that makes some sense, they're probably just bit-banging the PUL (manually setting it high and low at the appropriate time)
<set_>
No wonder we are at each others' throats here. Hmm.
<zmatt>
that's not really feasible from linux
<set_>
Aw. Great. My lesson is here...
<set_>
Sheesh.
<set_>
So, I am up fresh water w/ a bunch of salt!
<set_>
I jumped into their forums thinking I could understand more.
<zmatt>
to properly control this stepper motor driver from a beaglebone you'd need to use PRU, but there's no way in hell you're going to get that working
<set_>
I think I may have perturbed people.
<set_>
Ha.
<zmatt>
or the easy way to use a stepper would be to use an intelligent stepper controller connected e.g. via i2c
<set_>
I got an LED to work once w/ the PRU.
<set_>
Right.
<set_>
Right. Right.
<set_>
H-Bridge?
<set_>
I had high hopes.
<set_>
Blah.
<set_>
Thank you.
<set_>
At least I know the motor works.
<set_>
Loud but nice and soothing.
<set_>
Sort of like a screaming baby in an Arcade arena.
<set_>
It ... nope ... dang
Guest18 has joined #beagle
<set_>
Okay and so, from what I currently understand. It is a smart switch w/ GPIO only. It handles on/off in three separate formats but all formats are gpio like w/ working w/ a Relay.
<set_>
Man...I was breaking my back to understand it all. My ankles are giving on me!
Guest18 has quit [Ping timeout: 260 seconds]
Guest18 has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
Guest18 has quit [Ping timeout: 260 seconds]
mattb0ne has joined #beagle
brook has quit [Ping timeout: 276 seconds]
<mattb0ne>
would it be bad to run a electromagnet in an open loop setup