<zmatt> jfsimon1981: presumably they infer the frame has ended based on the higher protocol layer, but that is not how the protocol is specified. the serial protocol layer considers a packet to consist of one address byte, a variable-size payload, and two crc bytes. it considers the payload to be opaque hence has no way to determine the end of a frame other than by recognizing the 3.5-char idle time
<zmatt> jfsimon1981: so, the device you have is broken, what they implemented is not modbus
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
Morshing has joined #beagle
Morshing has quit [Remote host closed the connection]
set_ has quit [Ping timeout: 256 seconds]
<mewt> Went ahead and grabbed a second BBB to replace dead NIC, will try and troubleshoot more at a later date I guess
<mewt> I still want to try the near/far loopback modes on the NIC though, maybe later tonight even
set_ has joined #beagle
<zmatt> jfsimon1981: anyway, if this thing was sold to you as a modbus device you can perhaps complain loudly to the manufacturer to try to get them to fix it. alternatively, if you want to make it work with extremely tight bus turnaround, your options are either using pru or perhaps use an rs485 transceiver with automatic driver-enable
Shadyman has joined #beagle
buckket has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 240 seconds]
buckket has joined #beagle
starblue has joined #beagle
<set_> The build is back on! Workin' and workin' to get this daughter card, the Cape, up and out!
<set_> First, w/out mcu and then...dun, dun, dun, dun. W/ mcu!
vd has quit [Quit: Client closed]
vd81 has joined #beagle
vivien1 has joined #beagle
vivien1 has quit [Client Quit]
CoffeeBreakfast has quit [Ping timeout: 256 seconds]
ikarso has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
vd81 has quit [Quit: Client closed]
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 240 seconds]
vivien1 has joined #beagle
vivien1 has quit [Client Quit]
vd has joined #beagle
starblue has quit [Ping timeout: 240 seconds]
<jfsimon1981> zmatt, yes now that i got it almost working like this, i'll probably polish the solution though. It involved modifying the library. This device works well with other monitorings, i'll see what manufacturer said about it.
vagrantc has quit [Quit: leaving]
JustBoB has joined #beagle
florian has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
CoffeeBreakfast has joined #beagle
<jfsimon1981> zmat, right, indeed it must not be the modbus spec, it was said to me the device was plugged into a box and properly read.
<jfsimon1981> zmat, That explains why I had so much trouble making libmodbus work, indeed the default lib. has a parameter for rts which is quite long, that is coherent with the 3.5 char silent.
Mahmoud has joined #beagle
<jfsimon1981> I can confirm, the device responds immediately after the request.50 microseconds or less
<jfsimon1981> That's on boot, single modbus request, first request+response, no possible frame error.
florian has quit [Remote host closed the connection]
CoffeeBreakfast is now known as hnv
Mahmoud has quit [Quit: Client closed]
<set_> Yes!
<set_> Give it to 'em, jfsimon1981. Shoe that modbus up!
<set_> For instance...
* set_ is a cheerleader to the electronics field for now!
Epakai has joined #beagle
Mahmoud has joined #beagle
<set_> How you say, lemme learneth moreth!
<set_> Sorry. Off to dabble.
<zmatt> jfsimon1981: 50 microseconds measured from where exactly? I do hope from the end of the last stop bit and not from the last rising edge (which is at the latest between the parity bit and the stop bit)
<zmatt> though either way that's insanely short, that's barely a bit-time
<zmatt> jfsimon1981: I'm honestly surprised this would work with other modbus masters, given how seriously it violates the spec
<jfsimon1981> i understand they respond as soon as the frame is received in full as you said.
<jfsimon1981> That and possible the rs485 needs a ground ref although it should not, are - apparently - what cost me 4 weeks delay ! 2 weeks to just understand why the lib modbus did'nt work and 2 to found a way around.
<jfsimon1981> But not I'm going to implement an accurate delay in the lib, so this workaround can work reliably.
<zmatt> what do you mean? it sounds like you want to eliminate any delay
<jfsimon1981> The kernel on BB has "Preempt" flag on. That can be leveraged i hope to make some part deterministic.
<zmatt> it will probably be worse than letting the kernel handle rts
<jfsimon1981> I mean RTS needs to be very precise and not wander off by few us as it does not, sometime causing overlap.
<zmatt> that requires pru or a hardware solution (rs485 transceiver with auto-driver-enable)
<jfsimon1981> Ye sif kernel can leverage the preempt, otherwise I think it's possible to make a specific usleep() that's not interrupted, though i might be wrong, on bbb thx to preempt (or at least better that the standard library function). i don't know yet
<zmatt> if using kernel control of rts is not stable enough (using a non-RT kernel may actually be more reliable than an RT kernel for that)
<jfsimon1981> as you mentionned PRU could be leveraged although i'm verty late on this project now ...
<zmatt> why are you still talking about usleep? I don't get what you're doing
<zmatt> and no, you will get interrupted regardless
<zmatt> since the kernel needs to service the uart interrupts
<zmatt> which is why allowing the kernel to manage the rts should always be better than doing it in userspace
<jfsimon1981> libmodbus uses it, and the frames somethime collide due to the way the library implements rts.
<jfsimon1981> I remind the same happened with letting kernel do.
<zmatt> sounds like it just sucks
<jfsimon1981> don't know
<jfsimon1981> have to make a few tests
<jfsimon1981> had the probe been implementing this a little better ... anyway.
<zmatt> honestly, if you really have only one bit-time of turnaround time, I seriously doubt you'll ever get this working properly in linux
<zmatt> (and from your description it still isn't clear to me whether you even have that much or whether that 50 us is the stop bit)
<jfsimon1981> i have hope
<jfsimon1981> can be a little tough but possible i guess
<zmatt> I sincerely doubt that
<jfsimon1981> joker is the pru at th emoment
<zmatt> not reliably
<zmatt> if you want an easy fix without having to learn to deal with pru, use the hardware solutionI mentioned
<zmatt> or find a modbus device that isn't broken
<zmatt> or get the manufacturer to fix their broken device
<jfsimon1981> client device
<zmatt> server (slave) device you mean? I thought the bbb was the client (master)
<jfsimon1981> very specific, we can do nothing about this, it has modbus but also a chemical something converter
<jfsimon1981> client = customer
<zmatt> ohhh
<zmatt> that makes more sense
<jfsimon1981> the customer probe (which is a slave)
<zmatt> so have them fix it... can't be that hard to at least insert that 3.5 bit-time delay (which still wouldn't make it behave according to the modbus spec, but would at least make it not insane to deal with)
<zmatt> before sending a response
<jfsimon1981> is something very small that i have to read from however this takes me, but the master has more jobs to do hence a linux bb is more a less required. Doing logs, usb writes, little bit passed the edge of what microcontroller alone could do.
<jfsimon1981> sure, the problem I think this device is implemented in many other oems products so making them to change it, might be possible,
<jfsimon1981> i asked them about this issue, no response yet
<zmatt> ughhh
<zmatt> so they made a hot mess and then made it your problem
<jfsimon1981> honestly i doubt i get too much support, so i'll work around
<jfsimon1981> yep i assume many other people have figures out and got it work anyway, or maybe did'nt see the issue because the specific way they implemented, more hardware solution without embedded os.
<zmatt> still sounds odd to me, normally you'd still have some turnaround time
<jfsimon1981> cant' request my customer to pay for this troubles ...
<jfsimon1981> i'll explain to the customer, he's comprehensive at the moment
<jfsimon1981> i'll post some pix so you can see what'shappening
<set_> Me too? Can I see?
ikarso has joined #beagle
Mahmoud has quit [Quit: Client closed]
danny has quit [Quit: The Lounge - https://thelounge.chat]
danny has joined #beagle
<jfsimon1981> Here's the link
danny has quit [Client Quit]
danny has joined #beagle
<jfsimon1981> i'd be interested to have your point of view on those frames ...
<jfsimon1981> Hardware layer RS-485, protocol Modbus-RTU, 19200 baud, 1 start bit, 1 stop bit, no parity bit.
danny has quit [Client Quit]
danny has joined #beagle
hnv has quit [Quit: Client closed]
hnv has joined #beagle
set_ has quit [Ping timeout: 256 seconds]
<jfsimon1981> behaves worse with the busy timer, tough issue.
<jfsimon1981> (busy timer is more accurate but keeps cpu busy).
buzzmarshall has joined #beagle
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #beagle
<jfsimon1981> zmat, kind of working on uart with rts support, seems to be better that the modified lib in user space. Thanks for this hint, I ruled this out a few weeks ago but i certainly had another issue back then. It's running seems about right.
<jfsimon1981> Will leave it running the com test for a few hours. A few time out and crc errors reports, might acceptable.
rcn-ee has quit [Remote host closed the connection]
rcn-ee has joined #beagle
hnv has quit [Quit: Client closed]
Shadyman has quit [Remote host closed the connection]
rcn-ee has quit [Ping timeout: 256 seconds]
argonautx has joined #beagle
hnv has joined #beagle
vagrantc has joined #beagle
set_ has joined #beagle
<set_> I made it back after cleaning up sticks! Here is my sign?
<set_> Oops. Wrong room.
<set_> BBB!
<set_> Things are working out for the AI so far. I erased everything on my SD Card and now I am rebuilding so slowly! Wish me luck?
<set_> tflite and opencv w/ python at the helm!
set_ has quit [Ping timeout: 256 seconds]
<hnv> wow... ´[´ is actually an executable. Cool.
dkaiser has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
lucas_ has quit [Remote host closed the connection]
lucas_ has joined #beagle
dkaiser has quit [Quit: Leaving]
<nerdboy> okay, what's the latest 2GB flasher image for bbb?
hnv has quit [Quit: Client closed]
rcn-ee has joined #beagle
rcn-ee has quit [Client Quit]
rcn-ee has joined #beagle
bzyx has quit [Quit: No Ping reply in 180 seconds.]
bzyx has joined #beagle
argonautx has quit [Quit: Leaving]
set_ has joined #beagle