The while loop below can be replaced with user application code. * Placeholder for user application code. XMC_DEBUG(("OS initialization failed\n")) Mbtcp_thread_id = osThreadCreate(osThread(mbtcp_thread), NULL)
CMD MODBUS POLL CODE
I found this is due to the osKernelStart() call never returning (is this 'normal' ?), despite the code below suggesting that execution continues after the call. Also, EtherCAT stopped working, which I found was due to it's polling function, MainLoop, no longer being called, from within the main.c loop, as below. I found that ModbusTCP, now running on a thread, was just as flaky as running RTOS-less.
![cmd modbus poll cmd modbus poll](https://www.netio-products.com/files/styles/netio_news_thumb/public/an/1032/an27-schmodbus-tcpwith-netio-4x-control-and-measure-lan-power-sockets-new.png)
I then copied over the Libraries\freemodbus-v1.5.0 folder, and set the include directories (ARM-GCC C Compiler > Directories) to be set the same, in the same order and positions:
CMD MODBUS POLL MANUAL
I also checked HW Signal Connections, Manual Pin Allocator, Manual Resource Assignment, were set the same. For all three APPs, and those they connect to, I checked theĬonnections were visually the same. I checked their Properties were set the same, too. This caused theĬMSIS_RTOS_0 and CMS_RTOS_RTX_0 APPs to be created. Then, I manually 'layered' into the ETHCAT_SSC_XMC48 project, elements from the example DAVE project for ModbusTCP comms, namely MODBUS_TCP_MODE_XMC47.īy layered, I mean manually implementing the ETH_LWIP_0 APP, checking all the Properties are set the same, including the checked 'Enable RTOS' box. I started with the example DAVE project for EtherCAT comms, namely ETHCAT_SSC_XMC48.Īnd again, got that working fine, serving up data fast, to the TwinCAT EtherCAT client. So I'm atĪ bit of a loss, if it's not main loop hanging, or interrupts, that are causing the ModbusTCP flakiness.Īn update: I've now tried going with RTOS. So I have a sys_check_timeouts call, in the main loop, as well as the ModbusTCP poll call.Īlso an LED toggle call, that shows me that nothing is hanging within the main loop, causing the flakiness. Lastly, I tried commenting within the main loop, everything except for ModbusTCP polling. So, seems just the presence of EtherCAT infrastructure within the project, Even the EtherCAT LAN cable.īut still, the ModbusTCP flakiness persisted. Infact, I electrically disconnected all external sources of interrupts other than ModbusTCP. I also have other priority 63 interrupt handlers in the project, so I tried lowering those also to 62. But that had no effect, on the ModbusTCP flakiness. Within the pre-strip copy of the 'merged' project, I notice that the interrupt handlers for the EtherCAT and ModbusTCPĪPPS, namely ECAT_SSC_0 and ETH_LWIP_0, both have the maximum DAVE interrupt priority, of 63. So, seems something about having EtherCAT infrastructure present, is causing ModbusTCP flakiness. And lo-and-behold, ModbusTCP robustness and performance, was restored. Try stripping out from the 'merged' project, the ECAT_SSC APP, the subsidiary clock-sync APPs,Īnd the EtherCAT callback code. Including comparing the APP properties, source code using WinMerge, etc, etc, and finding noĭifferences at all in the ModbusTCP implementation, I had a thought: One adaptor is onboard, the other two are USB-to-LAN devices.Īfter many hours of comparing all elements of my 'merged' project, with my ModbusTCP-only project, I have three LAN adaptors on my PC, one each for EtherCAT, ModbusTCP, and corporate LAN. Although if I wait long enough, it also stops. Infact, I could only get ModbusTCP to run for any length of time, by specifying a ModPoll poll rate, of 100 ms Modpoll can be restarted, but only runs for a few seconds, before another error. Or, starts reporting continual 'Invalid MPAB indentifer!' errors, ModPoll can be stopped with Ctrl-C as usual. But unfortunately, the ModbusTCP becomes flaky:Īfter a few seconds running, ModPoll stops with a 'TCP/IP connection was closed by remote peer!' error.
![cmd modbus poll cmd modbus poll](https://www.modbustools.com/images/mbpoll-save-copy-series.png)
Now, I try 'merging' the two projects, so I have EtherCAT and ModbusTCP, within the same project. I can do anything I like on my PC, and there are no upsets to the ModbusTCP comms. If I try dropping the specified poll rate, to 1 ms (option -l 1), then I achieve a measured poll rate of around 710Hz. I achieve a poll rate, measured using an incrementing counter and stopwatch, of around 990Hz. Per the following command line, I'm reading 4 registers, addresses 1-4: I can use the following modpoll command line, reading 4 integers, with the minimum specifiable poll rate, of 0 ms Specification, is to perform reads with each at 1kHz, or as near to that as can be achieved.įor each, comms is running nice and fast.
![cmd modbus poll cmd modbus poll](https://user-images.githubusercontent.com/37483886/89884608-13c86b80-dbca-11ea-8bcb-351a842452a4.png)
I've got both working individually, based on the respective example DAVE projects. I'm working on an XMC4800 project, that requires EtherCAT comms and ModbusTCP comms.