https://forge.codesys.com/u/bwayt/activity/2021-09-08T18:55:43.998000ZRecent activity for bwayt2021-09-08T18:55:43.998000Z2021-09-08T18:55:43.998000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/64c144015a/?limit=25#6b7b

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.

2021-09-08T18:05:37.742000Z2021-09-08T18:05:37.742000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/64c144015a/?limit=25#8e8b

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...

2021-09-08T17:54:35.642000Z2021-09-08T17:54:35.642000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/780175db85/?limit=25#4ae1/b3ad

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!

2021-09-07T21:32:41.074000Z2021-09-07T21:32:41.074000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/780175db85/?limit=25#bc59

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...

2021-09-07T20:00:46.567000Z2021-09-07T20:00:46.567000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/780175db85/?limit=25#bc59

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...

2021-08-26T18:47:55.951000Z2021-08-26T18:47:55.951000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/4e2eb80123/?limit=25#df8b/fa68

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?

2021-08-25T22:30:26.905000Z2021-08-25T22:30:26.905000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/4e2eb80123/?limit=25#da76/350b

(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?

2021-08-24T20:08:09.544000Z2021-08-24T20:08:09.544000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/4e2eb80123/?limit=25#53d5

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)...

2021-08-23T17:45:45.989000Z2021-08-23T17:45:45.989000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Engineering/thread/4a9b1ad8f6/?limit=25#0685

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

2021-08-19T22:23:56.266000Z2021-08-19T22:23:56.266000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/80ca780e26/?limit=25#7ed3/bb06

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.

2021-08-19T22:20:21.874000Z2021-08-19T22:20:21.874000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Engineering/thread/4a9b1ad8f6/?limit=25#7369

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.

2021-08-19T16:09:05.464000Z2021-08-19T16:09:05.464000Zbwaythttps://forge.codesys.com/u/bwayt/profile/https://forge.codesys.com/forge/talk/Runtime/thread/80ca780e26/?limit=25#1376

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...