Open ShadeTechnik opened 5 months ago
And I wasn't the first one either. If you don't do code I think you will struggle with this, after the pcb is made it is all about programming. In the first pcb I did include connector J4 for access to the second I2C bus, haven't used it but should be straight-forward I think. There are many examples on how to program I2C so the function as such should be possible. Just keep in mind that everything works in cycles of 1 millisecond, and one can possibly spend 300-400 microseconds doing things like checking i2c bus. Or make it interrupt-driven in the background.
I haven't put up a video for a while now. Still stuck in step generator. It works but not good enough, and I thought I should make it work fine first. The PCB seems to work fine so you can take that as basis for you own design.
Den tors 28 mars 2024 kl 21:49 skrev ShadeTechnik @.***
:
Came across this whole project as I was actually in the middle of working on almost the exact same thing, then realized I wasn't the first one to have the idea which is good cuz I can't code to save my life lol.
Anyway once I get finished with my PCB I hope to be able to use this code. One thing I was curious about is if you thought about adding support for I2C IO expanders. I created a keypad a little while ago that has 4 MCP23017's that I'm eventually going to have to work into my project.....but like I said, I don't do code lol.
— Reply to this email directly, view it on GitHub https://github.com/MetalMusings/MyOwnEtherCATDevice/issues/6, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY7HWRIROKKQK5MLKRWHGTY2R66XAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTIMJSGA2DOMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Yeah it'll be a bit of a chore for me to get it going but I've got a friend that can hopefully help me out.
The PCB isn't really a concern, I'm just EtherCAT-izing an existing PCB. The one I'm currently working on is a bit more simple, it's for a control panel so it doesn't need the stepgens. From what I'm looking at so far (please correct me if I'm wrong) you used the timer based encoder peripherals. I need like 4 encoders, but much lower performance. The timer peripherals cause conflicts with other peripherals so I was just going to use an interrupt based encoder library.
Once I get this sorted out and working maybe I'll do something for higher performance encoders and stepgens, this one's hopefully going to solve some other issues I had and just get me into the world of EtherCAT. Do you have an email or some way to contact in case I have questions if you don't mind?
I think four of the timers have quadrature counting built-in and that's what I was using. I am aiming for 100 kHz at least, that should be no problem. If you look in the source code I think tim1, tim2, tim5 and tim8 are prepared for in the stm32encoder,cpp file. Those pins are fixed position but often other pins can be moved around. On the other hand it shouldn't be a problem to use interrupt based encoder counting. Just be aware that if you attach an interrupt to, say, pin PB9, you can not attach interrupts to PA9, PC9, PD9, PE9. This goes for all numbers. And you need to handle the counter overflowing when turning many revs, but that's kind of standard.
The interface to the LAN9252 is pretty clean. SPI(data, clock, chip select), INT, SYNC0, SYNC1 (and RESET, but I don't think LAN9252 has that line, the ax58100 does) are the lines you need to work with on the MCU. Possibly make changes for those pin numbers in the SOES library code. Place SPI with hardware support, you want to run SPI at 40 MHz or above.
Most of the functions are not that extremely timing dependent, stepgen stands out there. I'll try to get some time now during eastern to make it work.
Den fre 29 mars 2024 kl 13:40 skrev ShadeTechnik @.***>:
Yeah it'll be a bit of a chore for me to get it going but I've got a friend that can hopefully help me out.
The PCB isn't really a concern, I'm just EtherCAT-izing an existing PCB. The one I'm currently working on is a bit more simple, it's for a control panel so it doesn't need the stepgens. From what I'm looking at so far (please correct me if I'm wrong) you used the timer based encoder peripherals. I need like 4 encoders, but much lower performance. The timer peripherals cause conflicts with other peripherals so I was just going to use an interrupt based encoder library.
Once I get this sorted out and working maybe I'll do something for higher performance encoders and stepgens, this one's hopefully going to solve some other issues I had and just get me into the world of EtherCAT. Do you have an email or some way to contact in case I have questions if you don't mind?
— Reply to this email directly, view it on GitHub https://github.com/MetalMusings/MyOwnEtherCATDevice/issues/6#issuecomment-2027188766, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY7HWSMRJY2X33G3QCUDO3Y2VOKXAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGE4DQNZWGY . You are receiving this because you commented.Message ID: @.***>
I'm actually using a smaller STM32 than you did, mine is just for a control panel and I'm using some of the GPIO from the LAN5952. I use STM32cubeIDE to check the peripherals for conflicts. I was only able to squeeze 1 timer based encoder out but that'll just be for an MPG, the others will be for like feedrate OR knobs and such so they don't demand any performance. I was able to get them all on interrupt lines without issue.
I think I managed to get my code wizard friend involved, I've asked him set me up a repo with the code arranged in a more idiotproof manner so hopefully I can follow it well enough to make necessary adjustments. He's not a machine/ethercat guy but he does do embedded programming.
I know you didn't really mention a reason for switching ESC chips but did you have some problem with the LAN9252? It's readily available and has what I need so it seems like my best bet, just curious if there's some reason I should not use it.
LAN5952 does have a nRST line. I'm debating tying it to the STM32 nRST and running them both to the same reset button.
You can't mix digital IO from the LAN9252 with MCU access using SPI. It's either or. Check PDI MODE SELECTION, first byte in the eeprom. One can use any MCU, not only one of the STM32s. I had it working on an esp32 and it worked just fine, don't think I saved that "port". It's not that much to do, mainly to get SPI working and then it works.
No I don't really have a problem with the LAN9252. I saw somewhere that there is a bit of SPI communication overhead and that guy got some disappointing reaction times. Not that it matters for linuxcnc. I have had a number of issues and I sometimes suspect the LAN9252 and at one point I thought I should at least try to eliminate that factor. So far it has turned out that LAN9252 works just fine and I haven't come to work the AX58100 yet. Another big plus for the LAN9252 is the data sheet. The LAN9252 has all details documented, the ax58100 does not.
Yes use one button for both, I have that on the ax58100 design. On the LAN9252 design nRST is constant pulled-up, doesn't seem to be a problem that it can't be reset. I do download new code and reset the MCU regularly during development and linuxcnc takes a few seconds pause and then its work with the new firmware.
Den sön 31 mars 2024 kl 03:02 skrev ShadeTechnik @.***>:
I'm actually using a smaller STM32 than you did, mine is just for a control panel and I'm using some of the GPIO from the LAN5952. I use STM32cubeIDE to check the peripherals for conflicts. I was only able to squeeze 1 timer based encoder out but that'll just be for an MPG, the others will be for like feedrate OR knobs and such so they don't demand any performance. I was able to get them all on interrupt lines without issue.
I think I managed to get my code wizard friend involved, I've asked him set me up a repo with the code arranged in a more idiotproof manner so hopefully I can follow it well enough to make necessary adjustments. He's not a machine/ethercat guy but he does do embedded programming.
I know you didn't really mention a reason for switching ESC chips but did you have some problem with the LAN9252? It's readily available and has what I need so it seems like my best bet, just curious if there's some reason I should not use it.
LAN5952 does have a nRST line. I'm debating tying it to the STM32 nRST and running them both to the same reset button.
— Reply to this email directly, view it on GitHub https://github.com/MetalMusings/MyOwnEtherCATDevice/issues/6#issuecomment-2028516229, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY7HWTQRS3MIVOSKZ4RMP3Y25ODVAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYGUYTMMRSHE . You are receiving this because you commented.Message ID: @.***>
You can't mix digital IO from the LAN9252 with MCU access using SPI. It's either or. Check PDI MODE SELECTION, first byte in the eeprom.
This I wasn't sure about. I initially thought this but the illustration on page 10 of the the datasheet suggests this is possible "Microcontroller Mode (via SPI)" appears to show the GPIOs being active. I could not find anything that states it either way definitively but from what I gathered the GPIOs are disabled using parallel HBI or "expansion mode" as those 2 modes used the GPIO pins for either host communication or the 3rd Ethernet port. Have you actually tested this?
I haven't picked up a LAN9252 dev board to test, it's actually easier for me to just produce a prototype PCB and tinker with that so I can't test it but it would be nice to be certain that you can't do this before I bother.
You are right, it can be mixed. Didn't see that. I wonder how that should be configured in the esi file. Are they on their own sync managers? Maybe that is best. Afaik SOES reads and writes the entire syncmanager contents for the RxPDO and TxPDO. Can't have the GPIOs there. There is an example esi file for pure Digital IO. I guess one can merge that with an esi file for the MCU part. Those are things that comes to mind when using the GPIOs.
Den sön 31 mars 2024 kl 16:29 skrev ShadeTechnik @.***>:
You can't mix digital IO from the LAN9252 with MCU access using SPI. It's either or. Check PDI MODE SELECTION, first byte in the eeprom.
This I wasn't sure about. I initially thought this but the illustration on page 10 of the the datasheet suggests this is possible "Microcontroller Mode (via SPI)" appears to show the GPIOs being active. I could not find anything that states it either way definitively but from what I gathered the GPIOs are disabled using parallel HBI or "expansion mode" as those 2 modes used the GPIO pins for either host communication or the 3rd Ethernet port. Have you actually tested this?
I haven't picked up a LAN9252 dev board to test, it's actually easier for me to just produce a prototype PCB and tinker with that so I can't test it but it would be nice to be certain that you can't do this before I bother.
— Reply to this email directly, view it on GitHub https://github.com/MetalMusings/MyOwnEtherCATDevice/issues/6#issuecomment-2028772762, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY7HWXYQETCS6LERB5UUPTY3AMUVAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYG43TENZWGI . You are receiving this because you commented.Message ID: @.***>
Well I'm hoping my friend can sort most of that out, what I have found in the datasheet:
12.5 Host Interface PDI The value in the Extended PDI Configuration Register is used if GPIOs are enabled (SPI w/GPIO).
12.14.30 EXTENDED PDI CONFIGURATION REGISTER The bit definitions of this register are dependent on the selected PDI mode (Process Data Interface field in the PDI Control Register): Digital I/O Mode or SPI Mode.
Have a look at this MicroChip HBI+ evaluation board. It combines GPIO with a PIC32. I checked in the software support files. There is an esi file that at a quick glance seems to combine GPIO with MCU data. https://www.microchip.com/en-us/development-tool/evb-lan9252-hbiplus
Den tis 2 apr. 2024 kl 17:10 skrev ShadeTechnik @.***>:
Well I'm hoping my friend can sort most of that out, what I have found in the datasheet:
12.5 Host Interface PDI The value in the Extended PDI Configuration Register is used if GPIOs are enabled (SPI w/GPIO).
12.14.30 EXTENDED PDI CONFIGURATION REGISTER The bit definitions of this register are dependent on the selected PDI mode (Process Data Interface field in the PDI Control Register): Digital I/O Mode or SPI Mode.
— Reply to this email directly, view it on GitHub https://github.com/MetalMusings/MyOwnEtherCATDevice/issues/6#issuecomment-2032318929, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY7HWXKOJESEABRMRTJPJ3Y3LC75AVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGMYTQOJSHE . You are receiving this because you commented.Message ID: @.***>
Came across this whole project as I was actually in the middle of working on almost the exact same thing, then realized I wasn't the first one to have the idea which is good cuz I can't code to save my life lol.
Anyway once I get finished with my PCB I hope to be able to use this code. One thing I was curious about is if you thought about adding support for I2C IO expanders. I created a keypad a little while ago that has 4 MCP23017's that I'm eventually going to have to work into my project.....but like I said, I don't do code lol.