Activity for bwayt
-
bwayt posted a comment on discussion Runtime 🇬🇧
The clock signal issue was due to the SPI default speed of 1.25 MHz(!); I have changed it to 1000 Hz and I can now see the clock signal perfectly. The oscilloscope also showed me that MOSI was sending bytes 0x88, 0x03 then 0x90, 0x00: the write commands referenced in the setup method. I wonder if this program is just never getting past the setup method.
-
Hello again! Previously I had written a simple program that write to a register and reads from it. It works beautifully. Now, I am trying to expand upon that and write a program that sets up the buffer board's mode, then continuously reads the encoder value from the 'CNTR' register. Unfortunately, now there isn't even a clock signal; and, when I go online, all values (except for constants) show as '???' (invalid value). My guess is that there's an issue with how I set up the Task Configuration, but...
-
I figured out what was wrong...dumb me :X I forgot that it was shifting out on the falling edge and therefore MOSI would lead SCLK; so the original signal is correct 😅 Anyways. Still don't know why SPI mode shows 4 at runtime, but it's obviously still on mode 0. Problem solved!
-
Hello all, I have made progress on SPI comm to my buffer board (hooray!), in that there is a decipherable SCLK and MOSI signal. However, I've noticed that the MOSI signal is bit shifted to the left by one; for example, trying to send 72 (#01001000) instead shows on the oscilloscope as #10010000. After a bit of research the consensus seemed to be that it is a SPI mode issue, and indeed, when I check my SPI parameters it shows a diMode = 4; which makes no sense. From the datasheet I can see that I...
-
Hello all, I have made progress on SPI comm to my buffer board (hooray!), in that there is a decipherable SCLK and MOSI signal. However, I've noticed that the MOSI signal is bit shifted to the left by one; for example, trying to send 72 (#01001000) instead shows on the oscilloscope as #10010000. After a bit of research the consensus seemed to be that it is a SPI mode issue, and indeed, when I check my SPI parameters it shows a diMode = 4; which makes no sense. From the datasheet I can see that I...
-
I'd like to ask about that last part. Why do we specify speed in the SPI_master options when we have to specify it anyway when we call .transferExt?
-
(SPI is enabled on the RPi) I took a look at that link and gave it a try, creating a class that extended SPI. It seems that CODESYS wants BeforeWriteOutputs, AfterReadInputs, and Initialize to be overloaded with a call to SUPER. Wouldn't that mean I'd also have to write the .xml file? Is there any way to get around this?
-
Hello all, I am trying to initiate SPI communication with a LS3667R buffer board (https://lsicsi.com/datasheets/LS7366R.pdf). Following suggestions for my previous post (https://forge.codesys.com/forge/talk/Runtime/thread/80ca780e26/?limit=25#7ed3/bb06), I decided to execute SPI communication directly in my PLC_PRG with a call to a "read" and "write" method; these methods in turn (ideally) start SPI communication using SPI_master.transferExt(pabyTxBuffer, pabyRxBuffer, udiLen, uiDelayus, udiSpeedHz)...
-
Detailed descriptions of the devdesc.xml tags can be found within this manual, particularly sections 6 and 7: https://manualzz.com/doc/26032991/codesys-control-v3-manual
-
Yeah, both using the same SPI driver sounds right: I'm sure when you state your device that Codesys makes certain assumptions about how comm protocols will be handled. By "soft drivers", do you mean drivers specified through an XML file + Library? I'm still not sure as to why we use such roundabout methods when RPI4 has its own SPI library to use; not like the buffer board has anything special about the way it sends its bytes.
-
Is there a post about the meaning of each XML tag in devdesc.xml? I've read the documentation (https://forge.codesys.com/drv/io-drivers/doc/Generic/), but it mostly only tells what values ought to be used, not what the actual tags mean.
-
A bit of background: I have a LS7366R buffer board (Link: https://lsicsi.com/datasheets/LS7366R.pdf) that I have successfully established SPI connection with on Arduino and Raspberry Pi 4B (via Python's spidev library). I am now trying to establish the same SPI comm via Codesys, but noticed that you must have a SPI device driver for your slave (there's posts about writing your own device drivers, but I feel out of my depth in that regard). My question is: why do I need to specify a driver for this...