**** BEGIN LOGGING AT Fri Apr 22 02:59:56 2022
Apr 22 10:45:30 <mattb0ne> Friday!!!!
Apr 22 10:46:24 <mattb0ne> soooo zmatt here?
Apr 22 10:46:51 <mattb0ne> we got wee bit of a problem with this dumb pin
Apr 22 11:18:22 <zmatt> mattb0ne: the overlay you showed doesn't include P9.13 / gpio 0.31 ?
Apr 22 11:18:38 <zmatt> what does  show-pins | grep P9.13   show?
Apr 22 11:22:50 <zmatt> aaaand gone again
Apr 22 11:41:58 <mattb0ne> the bealge does not have unistd.h?
Apr 22 11:42:08 <mattb0ne> i need a delay
Apr 22 11:42:32 <zmatt> 23:37 <@zmatt> mattb0ne: there shouldn't be any __delay_cycles at all since your code is synchronized to the measurement rate of the load cell
Apr 22 11:42:39 <zmatt> 23:38 <@zmatt> i.e. adding __delay_cycles() does not change the rate at which your loop runs, it just reduces the time available per loop iteration until it fails to process the load cell data and faults
Apr 22 11:42:52 <mattb0ne> right
Apr 22 11:43:03 <mattb0ne>  i took that out but my code is still running too fast
Apr 22 11:43:23 <zmatt> how is it "too fast" ?
Apr 22 11:44:28 <zmatt> the way your program currently works means it will inherently operate at the sample rate of the load cell
Apr 22 11:44:40 <zmatt> and the only way to change that is by changing the sample rate of the load cell
Apr 22 11:44:42 <zmatt> not by adding a delay
Apr 22 11:45:19 <zmatt> (or _completely_ redesigning how the program works, changing the structure into something way more complicated than it currently is)
Apr 22 11:46:14 <zmatt> my suggestion would be to just run the PID loop at whatever rate you're currently getting, instead of deciding it is "too fast"
Apr 22 11:46:35 <zmatt> generally spaeking, running a loop faster is a good thing and makes it easier to tune
Apr 22 11:47:31 <mattb0ne> but I am not tracking time elapsed so I tick through the points on each loop pass
Apr 22 11:47:38 <mattb0ne> I guess I could play with that
Apr 22 11:47:46 <mattb0ne> getting a weird assert erro
Apr 22 11:47:50 <mattb0ne> error
Apr 22 11:48:23 <zmatt> ?
Apr 22 11:48:27 <mattb0ne> https://pastebin.com/ZD0j8DSr
Apr 22 11:48:47 <mattb0ne> the core check is breaking at like 134 which is asserting the message sizee
Apr 22 11:48:58 <mattb0ne> never seen that before
Apr 22 11:49:11 <mattb0ne> I wanted to add the input and output signals to the message
Apr 22 11:49:14 <zmatt> ehh, why did you put the PID parameter calculation *inside* the loop ?!
Apr 22 11:49:36 <mattb0ne> oh crap
Apr 22 11:49:40 <mattb0ne> I was cutting and pasting
Apr 22 11:49:40 <zmatt> Message must be a multiple of the max alignment, i.e. 4 bytes
Apr 22 11:49:43 <mattb0ne> did not meat to do that
Apr 22 11:49:54 <zmatt> otherwise if you have two adjacent messages, the second one would be misaligned
Apr 22 11:50:35 <mattb0ne> I will add another int16
Apr 22 11:50:39 <zmatt> the assert is a sanity-check I added exactly to catch mistakes like this :)
Apr 22 11:53:58 <mattb0ne> so the 16 bit alignment is for python and the 4 byte is for C
Apr 22 11:54:07 <mattb0ne> just so I have this clear
Apr 22 11:54:07 <zmatt> ??!?
Apr 22 11:54:41 <zmatt> no, all of the alignment requirements are to ensure structure compatibility between PRU and ARM
Apr 22 11:54:47 <mattb0ne> <zmatt> no, multiple of 2 bytes (16 bits)
Apr 22 11:54:48 <mattb0ne> <zmatt> not multiple of 16 bytes
Apr 22 11:55:31 <zmatt> the alignment requirement is exactly the same in all cases: fields need to be naturally aligned, i.e. a 4-byte (32-bit) integer needs to be 4-byte aligned, a 2-byte (16-bit) integer needs to be 2-byte aligned
Apr 22 11:56:51 <zmatt> this also implies a structure needs to be aligned in memory to whatever is the largest alignemnt required by any of its members
Apr 22 11:57:41 <zmatt> which also implies that if you have an array of some structure (e.g. Message), the size of the structure needs to be a multiple of its alignment
Apr 22 12:02:38 <mattb0ne> ok
Apr 22 12:03:00 <mattb0ne> and if I have a mix
Apr 22 12:03:22 <mattb0ne> just align to the biggest one so 4 byte since I have uint32?
Apr 22 12:03:58 <mattb0ne> my last major problem is the GPIO pin
Apr 22 12:04:02 <mattb0ne> not switching
Apr 22 12:04:48 <mattb0ne> I posted my overlay last night
Apr 22 12:05:29 <mattb0ne> https://pastebin.com/5QxrRsYW
Apr 22 12:05:40 <mattb0ne> I can change the pin state from python
Apr 22 12:07:09 <zmatt> hopefully this clarifies the issue... this is two consecutive Messages with the structure you were using: https://pastebin.com/raw/bMnN6NkX
Apr 22 12:08:23 <zmatt> I don't see gpio0.31 in your overlay
Apr 22 12:09:29 <zmatt> the gpio will need to be configured as output, whether by overlay or by software (e.g. python), before using PRU to control the output
Apr 22 12:11:38 <zmatt> also your logic doesn't make sense... you're setting direction based on whether the control_signal is negative or positive, yet you're limiting the control signal to range 600..4000 which is never negative
Apr 22 12:11:55 <zmatt> also, you seem to have forgotten about the right-shifting
Apr 22 12:13:40 <zmatt> I'm also confused why you're checking the raw position (not relative to the reference position) for something
Apr 22 12:14:25 <zmatt> also, why is your indentation such a terrible mess? :/
Apr 22 12:15:26 <mattb0ne> lol
Apr 22 12:15:44 <mattb0ne> good point on the direction
Apr 22 12:20:11 <zmatt> btw, does https://pastebin.com/raw/bMnN6NkX actually make it clear why your version of struct Message was a problem and why adding another 16-bit field to it fixes the problem?
Apr 22 12:20:23 <mattb0ne> yes it does
Apr 22 12:20:25 <mattb0ne> thanks
Apr 22 12:20:28 <zmatt> because I feel like I've had to explain alignment way too make times already
Apr 22 12:20:36 <mattb0ne> how did you make that box thing
Apr 22 12:20:36 <zmatt> *too many
Apr 22 12:20:40 <mattb0ne> htrml
Apr 22 12:20:47 <mattb0ne> html
Apr 22 12:20:49 <zmatt> those are just box drawing characters
Apr 22 12:21:09 <zmatt> it's plain text
Apr 22 12:21:51 <mattb0ne> I had an outdated overlay
Apr 22 12:21:52 <mattb0ne> https://pastebin.com/tuEQ9keR
Apr 22 12:21:59 <mattb0ne> this one has the motor pin I am interested in
Apr 22 12:23:06 <zmatt> if show-pins confirms the gpio is configured as output, pru *should* be able to change it just fine... but if it doesn't I can't diagnose that right now, gotto go to work
Apr 22 12:23:40 <mattb0ne> ok
Apr 22 12:23:56 <mattb0ne> np
Apr 22 12:23:59 <mattb0ne> thanks for the lesson
Apr 22 12:37:40 <mattb0ne> i ditched the bit shifting in favor of just the raw counts btw
Apr 22 12:37:50 <mattb0ne> so I am working with integers
Apr 22 12:38:00 <mattb0ne> basically the same thing
Apr 22 12:38:04 <mattb0ne> i just do it on my input file
Apr 22 13:32:29 <zmatt> mattb0ne: ehh, that doesn't change that you currently have very little resolution in your coefficients and way more range in your output value than you need
Apr 22 13:33:31 <zmatt> the input value has no relevance here, that uses the same scale as the measured value (i.e. the encoder position), while I'm talking about the output value and coefficients
Apr 22 13:48:00 <mattb0ne> so I should still shift
Apr 22 13:48:01 <mattb0ne> ok
Apr 22 13:50:15 <zmatt> well, it'll increase the resolution available for your coefficients
Apr 22 13:56:22 <mattb0ne> is this a formal technique?
Apr 22 14:19:55 <zmatt> uhh, yeah?  effectively it's using fixed-point arithmetic
Apr 22 14:24:06 <mattb0ne> hahaha
Apr 22 14:24:30 <zmatt> ?
Apr 22 14:24:42 <mattb0ne> i am just imagined you saying that
Apr 22 14:24:55 <mattb0ne> and the incredulous look on your face when you typed it
Apr 22 14:25:05 <mattb0ne> just funny
Apr 22 14:25:07 <mattb0ne> that is all
Apr 22 14:27:04 <zmatt> basically, if you'd want to know the integer part of 12.345 * 120 you can calculate 12345 * 120 and then drop the last three digits, i.e. right-shift by three digits
Apr 22 14:27:17 <zmatt> this is the same, except of course using bits rather than digits
Apr 22 14:28:06 <zmatt> so if you right-shift your output value by 16 before using it as pwm value, you effectively give your coefficients 16 bits after the decimal point
Apr 22 14:34:04 <mattb0ne> I see but I would need to scale it back to fit the PWM requirements
Apr 22 14:34:08 <mattb0ne> right?
Apr 22 14:34:38 <zmatt> ?
Apr 22 14:42:51 <zmatt> https://pastebin.com/jbRyDiUw   or something
Apr 22 14:43:20 <zmatt> and of course then your coefficients need to be much larger, but you presumably still need to tune those anyway
Apr 22 14:43:42 <zmatt> and you'll generally want to start with small values
Apr 22 14:45:28 <zmatt> instead of using a periodic signal it would also be sensible to start with just following a single value that you read from shared memory (i.e. a signal of length 1) so you can see how the control loop responds to manual changes of the input value
Apr 22 14:50:01 <mattb0ne> good idea!
Apr 22 21:17:05 <mattb000ne> ok the motor almost chopped my fingers
Apr 22 21:17:23 <mattb000ne> I need to figure out this timing thing
Apr 22 21:20:24 <mattb000ne> the motor just sits there until i nudge it forward then it takes off
Apr 22 21:21:02 <mattb000ne> I also think it is blowing through my checks as it seems to be runnning at rated speed. The cap I have should block that
Apr 22 21:21:07 <mattb000ne> not sure what is going on
Apr 22 21:25:02 <mattb000ne> need some food
Apr 22 21:25:14 <mattb000ne> also that pin is still not switching
Apr 22 21:25:32 <mattb000ne> as a stop gap I will control from python but it will be slower
Apr 22 21:38:38 <mattb000ne> break time!
Apr 22 22:56:07 <Guest67> Too much trial and error in google answers on Debian and BBB. I want to hire $$ someone to give me a head start on configuring the BBB. Staff augmentation for my computer engineering dept, we do not have the right experience to jumpstart the BBB in a new project. Where does one go to hire a consultant?
**** ENDING LOGGING AT Sat Apr 23 02:59:56 2022