<zmatt>
also, output_signal is abs(control_signal >> 16) but you then calculate that a second time to actually set EPWM1A ... that's obviously not very useful. also, now that I think about it it would probably make more sense to use (abs(control_signal) >> 16) instead
<zmatt>
and you probably want to log the full 32-bit control_signal to python, not its reduced-precision absolute value
<mattb0ne>
I assign a value of 600 to the shmem.signal limit variable
<mattb0ne>
but the PRU passes back 136
<zmatt>
how are you passing it back? also, maybe check whether the SharedVars defined in the PRU code matches the one defined in python?
<mattb0ne>
it matches
<mattb0ne>
how do I log the full 32bit
<mattb0ne>
control value
<zmatt>
by passing control_signal instead of output_signal to send_message() ... the parameter is already 32-bit
<zmatt>
in fact the output_signal variable has no reason to exist
<mattb0ne>
ok
<zmatt>
00:57 <@zmatt> btw, I asked earlier but you haven't responses: why are your control_signal limits commented out? that seems like a bad idea
<mattb0ne>
I was capping it for the motor since I did not want it to run to fast. Now I have an electromagnet and I would want to use 100% of the 24VDC if needed
<zmatt>
then set the bounds to whatever the max pwm value is (and its negative)
<zmatt>
which depends on how the pwm output is configured
<mattb0ne>
so I initialize by passing the period,and divider (which is 1) to the init function of the pwm
<zmatt>
what period?
<mattb0ne>
period is 100e6/10000 or 10000
<zmatt>
then your control signal limits should be (10000 << 16) and -(10000 << 16)
<mattb0ne>
ok
<zmatt>
oh hm I just realized that this way of imposing a control limit may not play nice with how the pid loop is implemented, especially since your PID is currently just P and no I
<zmatt>
but not having limits is also a bad idea, especially once you set your I non-zero
<mattb0ne>
yeah I was going to add an I and D
<mattb0ne>
was starting with the tuning process
<zmatt>
you generally do want at least PI yes
<mattb0ne>
when I noticed that my control signal looked weird
<mattb0ne>
the issue is defiinitely the counter variable not getting to 600
<mattb0ne>
but I am not sure why it is resetting
<mattb0ne>
cycle count is toggling early means the signal limit variable is not correct
<zmatt>
try putting assert( signal_length == 600 ); right before your main loop
<zmatt>
like, there's not really any way for it to wrap early unless the signal_length is wrong, so I'm assuming that assert will indeed abort
<zmatt>
but I really don't see how signal_length could be wrong unless PRU and python disagree on the structure of SharedVars
<mattb0ne>
yeah it aborted
<zmatt>
or something is going horribly horribly wrong somewhere and SharedVars is getting clobbered by something, but if that's happening then you'd be able to tell by inspecting the value of shmem.signal_length from python
alan_o has quit [Remote host closed the connection]
alan_o has joined #beagle
<mattb0ne>
so it must get overwritten
<mattb0ne>
it will spit back out 600 after assign it
<mattb0ne>
i do not know if I really tested anything putting a print statemetn after assigning it but
<mattb0ne>
it did give the right answer
<zmatt>
no you're not, check its value after pru aborts
<mattb0ne>
is core abort something i can put in the catch block in python?
<zmatt>
ehh it's not an exception unless your code is raising it itself
<mattb0ne>
if I put it in the finally block would that work?
<zmatt>
note that "abort" here isn't a concept of pru itself, it's something defined in your code, it just puts the file+line in shared memory and then halts the pru core
<zmatt>
... just check where your code is checking the core has halted?
<mattb0ne>
yeah it is haulting at hte assert
<mattb0ne>
ok
<mattb0ne>
will do
<zmatt>
like, your python code is explicitly checking whether the core has halted
<zmatt>
print shmem.signal_length there, at the point your code has determined the core has halted
<mattb0ne>
i added it there and it says 600
<mattb0ne>
I can pastebin my pru and python code
<mattb0ne>
weird
brook has quit [Remote host closed the connection]
<zmatt>
then it's a mismatch between SharedVars defined in PRU and defined in python, or you have misaligned fields in that struct (which result in them disagreeing even if you declare the same fields in the same order), or they're equal in source code but you forgot to recompile the PRU code after a change :P
<mattb0ne>
I was careful to presever the 32bit blocks
<mattb0ne>
i will pastebin
<mattb0ne>
my definition
<zmatt>
yep, pastebin the definitions in pru and in python
<mattb00ne>
i updated to put the signal length and pass it back
<zmatt>
look more closely :P
<mattb0ne>
is it the char const?
<zmatt>
your PRU code has an "uint32_t time;" between abort_line and ridx
<zmatt>
which is missing from your python structure
<mattb0ne>
aaahhhhh
<mattb0ne>
i was only looking at the bottom
<zmatt>
well that's not a very effective way to verify two structures are identical :P
<zmatt>
I'm not sure what to do about the control-limit... I guess omit it for now
<zmatt>
as long as your Ki coefficient is zero you don't need it
<mattb0ne>
ok
<mattb0ne>
I will probably add it back in as I get the tuning going a bit
<zmatt>
it may not be needed, and I'm not sure the current implementation is a good one anyway
mattb00ne has quit [Ping timeout: 260 seconds]
<mattb0ne>
ok
<mattb0ne>
afk for a store run before they clsoe
<zmatt>
you may instead just want an abort() if the integrator gets too large (indicating a failure to converge), but that's a problem with how the pid algorithm is currently implemented since the integrator currently doesn't have its own state, control_output is abused for that instead
<zmatt>
(but the integrator isn't the only contributor to the control_output, so limiting the latter really isn't the same as limiting the former)
mattb0ne has quit [Ping timeout: 268 seconds]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Remote host closed the connection]
am0nshi has joined #beagle
<am0nshi>
Hey guys, is it possible to get docker image of OS stored in BBB? I need to develop some automation / deployment scripts and docker looks like a great solution
<zmatt>
am0nshi: I mean, you can't really boot an image for the BBB in a VM
<zmatt>
it has hardware-dependent stuff
<zmatt>
but also, I'm not too familiar with Docker but isn't it intended for containerized applications rather than running OS images?
<zmatt>
like, what are you trying to do exactly?
<zmatt>
like, you can spawn a shell (and therefore run scripts) "in" a beaglebone image using systemd-nspawn and qemu-user-static, that avoids actually booting the image hence avoids most of the headaches, and is sufficient to e.g. install packages
am0nshi has quit [Quit: Client closed]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
mattb0ne has joined #beagle
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #beagle
<mattb0ne>
no set toinght
mattb0ne has quit [Ping timeout: 250 seconds]
mattb0ne has joined #beagle
vagrantc has quit [Quit: leaving]
mattb0ne has quit [Ping timeout: 250 seconds]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 255 seconds]
brook has joined #beagle
ikarso has joined #beagle
SJFriedl has quit [Read error: Connection reset by peer]
Myrtales_ has joined #beagle
Myrtales has quit [Ping timeout: 248 seconds]
rob_w has joined #beagle
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 276 seconds]
ft has quit [Quit: leaving]
mattb0ne has joined #beagle
florian has joined #beagle
Shadyman has quit [Remote host closed the connection]
_av500_ has joined #beagle
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #beagle
av500 has quit [Ping timeout: 268 seconds]
av500 has joined #beagle
mattb0ne has quit [Ping timeout: 250 seconds]
_av500_ has quit [Ping timeout: 255 seconds]
mattb0ne has joined #beagle
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #beagle
mattb0ne has quit [Ping timeout: 255 seconds]
mattb0ne has joined #beagle
<mattb0ne>
why cant i be connected to a VPN and irc server
<zmatt>
do you mean connected to an actual VPN while connected to irc normally via the internet, or do you mean connected to irc through a VPN tunnel?
<zmatt>
because in the latter case if your irc connection is getting refused with the error "SASL access only" it means you need to have your nickname registered and configure your IRC client to use SASL authentication ( https://libera.chat/guides/sasl )... this restriction is imposed on IP ranges which "are the source of frequent policy violations due to providing easy access to dynamic addresses to a wide ...
<zmatt>
...range of users. These ranges are typically used by VPN, cloud-computing, and mobile network providers."
mattb0ne has quit [Ping timeout: 260 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 264 seconds]
SJFriedl has joined #beagle
otisolsen70 has joined #beagle
brook has quit [Ping timeout: 256 seconds]
brook has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
when I connect to a vpn my existing connection to the irc server gets cut and I cannot connect until I stop the vpn
<mattb0ne>
brb
mattb0ne has quit [Remote host closed the connection]
<zmatt>
mattb0ne: is the intent of the VPN to access systems that are not otherwise accessible from the internet, or is the intent to route all your internet traffic through it? since evidently the latter is happening if your existing connection to the irc server gets cut, and your inability to then connect is presumably a firewall policy of that remote network
<zmatt>
(especially if you can access other things like google.com just fine)
<zmatt>
like, I use a VPN to access the office network, but it's setup such that only connections to the local IP ranges used at the office are routed through the VPN, not packets that would get routed to the internet (the remote VPN endpoint also doesn't allow such traffic)
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
brook has quit [Remote host closed the connection]
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
brook has joined #beagle
buzzmarshall has joined #beagle
alan_o has quit [Read error: Connection reset by peer]
alan_o has joined #beagle
ikarso has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
rob_w has quit [Quit: Leaving]
av500 has quit [Ping timeout: 260 seconds]
brook has quit [Remote host closed the connection]
brook has joined #beagle
xet7 has quit [Ping timeout: 260 seconds]
xet7 has joined #beagle
brook has quit [Ping timeout: 276 seconds]
brook has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
brook has quit [Remote host closed the connection]
brook has joined #beagle
ft has joined #beagle
PhotoJim has quit [Ping timeout: 246 seconds]
PhotoJim has joined #beagle
vagrantc has joined #beagle
otisolsen70_ has joined #beagle
otisolsen70_ has quit [Remote host closed the connection]
otisolsen70 has quit [Ping timeout: 250 seconds]
zjason`` has joined #beagle
zjason` has quit [Ping timeout: 276 seconds]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 256 seconds]
brook has joined #beagle
Guest82 has joined #beagle
Guest82 has quit [Ping timeout: 260 seconds]
brook has quit [Remote host closed the connection]
brook has joined #beagle
buzzmarshall has quit [Remote host closed the connection]
brook has quit [Remote host closed the connection]