#linuxcnc-devel Logs

Sep 15 2022

01:13 AM pere: Have a look at "less +2650 src/emc/usr_intf/pncconf/dialogs.glade". I just noticed it. What is the purpose of translating a bunch of spaces? <URL: https://hosted.weblate.org/search/linuxcnc/linuxcnc/?offset=1&q=+source%3A%3D%22++++++++++++++++++++%22+&sort_by=-priority%2Cposition&checksum= > show the status.
02:28 AM mrec: I wonder how allegro could loose against those shitty austrian microsystems encoder
02:30 AM mrec: allegro supports programming their encoder a few times, while AS only supports it once
02:30 AM mrec: it took me like a few minutes to set up allegro.. while I'm sitting here for a few hours on the austrian microsystems part and getting unexpected replies via spi
02:31 AM CaptHindsight[m]: first thought when I hear Allegro https://www.cadence.com/en_US/home/tools/pcb-design-and-analysis/pcb-layout/allegro-pcb-designer.html
02:32 AM mrec: no version register so I cannot even verify what's right or wrong
02:32 AM mrec: (on the ats shitty part)
02:33 AM mrec: considering that AS has many of those encoders they should have a version register that would be the most basic I'd expect from a chipdesigner when doing such a product line
02:33 AM mrec: they have many encoders..
05:07 AM mrec: did anyone use the AS5047p with linuxcnc?
05:08 AM mrec: that IC seems to be very odd... I'm ettin framing errors periodicly from it
05:08 AM mrec: compared with the allegro part, allegro does not have any kind of checksum for the communication and it all works out well quickly
05:14 AM -!- #linuxcnc-devel mode set to +v by ChanServ
05:31 AM -!- #linuxcnc-devel mode set to +v by ChanServ
05:31 AM JT-Cave: I guess the pcie nic is bricked
05:32 AM pere: hi
05:39 AM pere: anyone know when the next videochat will take place?
05:43 AM mrec: ok dumped the chip austrian microsystems can go to hell with their IC
05:44 AM mrec: getting lots of values back but they made no sense
05:44 AM mrec: parity permanently failing
06:16 AM silopolis[m]: <pere> "anyone know when the next..." <- Nope
06:16 AM pere: :(
08:06 AM rmu: mrec: sounds like you have some kind of framing errors on you SPI
08:23 AM mrec: I do not see any error there
08:24 AM mrec: I'm sending transactions 16 bit (within one CS low transaction)
08:24 AM mrec: afterwards reading another 16bit within another CS low transaction
08:24 AM mrec: the random numbers are always within the same cs low transaction (the second one of course)
08:25 AM mrec: I'm using the second board now since I dumped the first one but it gives the same results
08:25 AM mrec: spi mode 1 is set, on the oscilloscope everything looks fine (except the very random angle data)
08:25 AM mrec: power is also stable 3.3v however I used it with 5V before but 1000ppr are too much for my setup
08:26 AM mrec: this chip seems to be a disaster since there's no way to verify that the communication is good at all
08:26 AM rmu: my experience with similar errors, in the end it was always user/programmer error and tired eyes ;)
08:27 AM rmu: and/or bad signal integrity
08:27 AM mrec: still the question would be how the chip can return so many different bad values that's not good
08:27 AM mrec: the wires are very short to the RPI
08:27 AM rmu: and datasheet says you can use CRC
08:28 AM mrec: ya absolute nonsense
08:28 AM mrec: the allegro magnetic sensor just worked within minutes however shitty austrian microsystems wiped the breakout boards from the market
08:29 AM mrec: I'd immediately dump AS .. I don't like the OTP functionality either Allegro can do that several times at least
08:30 AM mrec: Received: b2 22
08:30 AM mrec: Received: 52 ad
08:30 AM mrec: Received: 5a a5
08:30 AM mrec: Received: f9 a5
08:30 AM mrec: Received: ec a2
08:31 AM mrec: Received: f9 1e
08:31 AM mrec: Received: 35 9f
08:31 AM mrec: the other spi frames do not receive any unwanted data
08:31 AM mrec: I move the board to an STM32 board... away from the RPI
08:34 AM rmu: does your oscilloscope trace match what you receive on the rpi?
08:35 AM mrec: yes
08:35 AM rmu: oh, CRC is in the 5047U, sorry
08:53 AM mrec: the only difference I see is that the RPI cannot do 16bit transfers
08:53 AM mrec: so there might be a small glitch between the 8th and 9th bit
08:54 AM mrec: considering that this chip is implemented a little bit crazy maybe that's the problem
08:56 AM mrec: I guess it will work if I power it with 5V
08:57 AM mrec: ABI seems to work with 3.3v the output is correct
08:58 AM mrec: however if the magnet is gone it pulses like crazy
08:58 AM mrec: reminds me about my heating in Berlin, once the battery of the sensor went empty the heating switched to 100%
08:58 AM mrec: seems like those engineers must be relatives
09:07 AM mrec: I'd be very curious why the angle value is changing if the ABI output is stable
09:08 AM mrec: the angle value however is somewhat the same
09:33 AM mrec: seems like it works now the chip is indeed not very flexible
09:34 AM mrec: I only need to program it to 100ppr as mentioned and then I'm back again to ABI which worked from the beginning on.
09:48 AM -!- #linuxcnc-devel mode set to +v by ChanServ
09:48 AM -!- #linuxcnc-devel mode set to +v by ChanServ
10:08 AM mrec: this ABI thing is really bad if the magnet disappears it's pulsing wildly
10:09 AM mrec: the designer of those Austrian Microsystems magnetic sensors is not really good.
11:01 AM -!- #linuxcnc-devel mode set to +v by ChanServ
12:02 PM -!- #linuxcnc-devel mode set to +v by ChanServ
02:12 PM -!- #linuxcnc-devel mode set to +v by ChanServ
02:17 PM -!- #linuxcnc-devel mode set to +v by ChanServ
05:40 PM -!- #linuxcnc-devel mode set to +v by ChanServ
07:50 PM -!- #linuxcnc-devel mode set to +v by ChanServ
08:06 PM -!- #linuxcnc-devel mode set to +v by ChanServ
08:07 PM -!- #linuxcnc-devel mode set to +v by ChanServ