<mattb0ne>
the major difference is me taking out the encoder read
<mattb0ne>
but the encoder was not my limiting step
<zmatt>
I don't really know what I"m looking at
<mattb0ne>
i have the pru code for the PID loop
<mattb0ne>
the second is the recoreded information comping from the the PRU
<zmatt>
your program is outputting 600 messages per second, corresponding to the 600 Hz samplerate of the load cell
<mattb0ne>
right
<mattb0ne>
but the plot says otherwise
<mattb0ne>
what is weird is the green trace
<mattb0ne>
which is the control signal
<mattb0ne>
it repeats 4 times in a second
<mattb0ne>
I should only be able to make one trace
<mattb0ne>
so it is either not getting to the end
<mattb0ne>
or something
<mattb0ne>
i am just started looking at it
<mattb0ne>
btb
<mattb0ne>
brb
<zmatt>
what's the signal_length you're communicating via shmem?
<mattb0ne>
600
<mattb0ne>
so I have a 1 second period
<zmatt>
you sure?
<mattb0ne>
i guess I could pass it back out to make sure
<mattb0ne>
good trouble shooting
<zmatt>
I notice you're putting the cycle_count in each message, maybe include that in your log
<mattb0ne>
ok
<mattb0ne>
let me try that
brook has quit [Remote host closed the connection]
<zmatt>
also why are your control_signal commented out? that seems like a bad idea
<zmatt>
*control_signal limits
<zmatt>
and is there a particular reason you keep the PRU running after it hits the cycle_limit ?
Shadyman has joined #beagle
starblue has joined #beagle
brook has joined #beagle
<zmatt>
mattb0ne: btw it's probably a good idea to disable the motor (EPWM1A = 0;) in abort_at() before halting the pru core
<zmatt>
also, currently your signal period is signal_length+1 instead of signal_length because your wrap condition is wrong... you're using counter > signal_length but it should be counter >= signal_length
<mattb0ne>
back
<mattb0ne>
oh
<mattb0ne>
ok I will gix
<mattb0ne>
fix
<mattb0ne>
one question I did have is currently I only use P9_14 for the ehrpwm1
<mattb0ne>
if I wanted full power would I need to use P9_16 as well
<zmatt>
???
<zmatt>
"full power" ? they're just two separate PWM outputs
<mattb0ne>
so you could control two devices
<mattb0ne>
one on each pin?
<zmatt>
... they're two separate PWM outputs. what you do with them is up to you. if you don't need the second output you don't need to pinmux it, the overlay is just an example that muxes both output pins of the pwm controller
<mattb00ne>
ok
mattb00ne has quit [Ping timeout: 260 seconds]
<zmatt>
btw, I asked earlier but you haven't responses: why are your control_signal limits commented out? that seems like a bad idea