2 followers Follow

FT 3120 stops transmitting to Lon network

I have an FT 3120 unit which acts as a gateway between a Lon network and a PLC which it communicates with using SPI.
I'm having the issue that after some seemingly random time it stops transmitting to the Lon network. If I restart it by cutting the power supply it starts working again.

Previously it stopped very often (approximately once per 10 minutes on average) but I improved on this by letting the code check the device error status. If an error code is reported, the status is cleared and then the node is restarted by using the following code:

status_struct status;
unsigned short logged_error;

logged_error = status.status_error_log;
if (logged_error != 0)
    node_status_to_plc_flag = TRUE;


node_status_to_plc_flag = FALSE;

nodeStatusToPLC() reads the status again and transmits this over SPI to the PLC where I can monitor the data. One weird thing is that even though this is only triggered if logged_error != 0, most of the time the reported error that I see is 0. Sometimes I get the error 138 which is domain error, I find this to be a bit odd since I never change the domain.

To test the program, 3 messages are sent to the unit over SPI every 25 ms, these messages are 10 bytes each. The unit transmits these on the Lon network using unacklowedged, non-repeated messages with explicit messaging. Two nodes in the network then responds to one message each, these responses are also 10 bytes each (+ Lon network overhead). These responses are finally transmitted over SPI to the PLC. To sum it up the FT 3120 transmits 3 messages and receives 2 on the Lon network every 25 ms.

For the SPI communication the FT 3120 is master and the SPI bus runs at 20 kBaud. When the error occurs I know that the FT 3120 is still receiving the SPI messages since I don't get a buffer overflow on the PLC side.
Also, if I generate a message from one of the nodes it is passed on to the PLC.

Messages received from the SPI are first put in a buffer before they are sent on the Lon network with the following code:

priority when (data_ready_for_lon_tx == TRUE)
if ( msg_alloc() )

msg_out.service = UNACKD;
msg_out.tag = explicit_tag;
msg_out.code = (ConfigMode == 8?MASTER_CODE:SLAVE_CODE); // Check if unit is configured as Node or Gateway
memcpy(, &lon_tx_buff[lon_tx_buff_r_ptr], sizeof(event_msg));

    //update buffer read pointer
    if (lon_tx_buff_r_ptr >= LON_TX_BUFF_SIZE)
        lon_tx_buff_r_ptr = 0;

    //check for empty buffer
    if (lon_tx_buff_r_ptr == lon_tx_buff_w_ptr)
        data_ready_for_lon_tx = FALSE;

        msg_out.dest_addr = msg_dest_addr; 


I'm running out of ideas to to test so I'm throwing it out here to see if anyone has any ideas about the cause of this.

Martin Markström

Official comment



Since you are using application messages, please make sure you have a default when clause in your code to trap unwanted application messages on the network. If you don't have such a clause, the device will eventually stop communicating.
Please see the Neuron C Programmer's guide, Importance of a Default When clause section.


Karelle Perrault
Comment actions Permalink

Please sign in to leave a comment.



I do have a default when clause:
But maybe there might be something to it anyway? My application is currently not processing the node responses fast enough so I see a lot of messages lost due to no application buffer available. I haven't really cared about this since I am currently only interested in that the system will not freeze under load. Can you explain the reason for why the device will stop communicating if I don't have a default clause? Is it related to no application buffer available? I understand from the section you referred to that it will lose incoming messages but I can't see that it mentions that the device would be unable to transmit messages.

Martin Markström 0 votes
Comment actions Permalink

Hi Martin

You would not be able to communicate with the device with any network management tool since it would not process any incoming requests. You are right that the device should be able to send unsolicited messages though.

I notice in your reset routine that you are clearing the node statistics to clear the last error logged. This means however you are loosing all counters which might give you indications as to what is going wrong. To investigate this, I would suggest to remove this "reset" feature as I believe it is just hiding/delaying the problem.
I notice you are getting an invalid domain error. Are you writing to the domain table in your application? How is the device commissioned?

It would be best if you can contact us on our official support channel at
The community web board is designed for the LonWors Community and is not the most efficient way to provide technical assistance.

Karelle Perrault 1 vote
Comment actions Permalink