Modbus fix

[vitico bon]

Yes, I saw that log in your project, but then I have to build it with my port parameters and records stop coming into the log. Just to try, I am installing now the Visual Studio Express 2015 in another machine to see what happen. Don't know if that version will be compatible with your product though. Let see.   

[Archie]

The version of Visual Studio shouldn't make the difference. Double check the driver instance and make sure you have EnableLogging set to True.

[vitico bon]

Here I am putting everything into the same pic. The numbers on the controller 1 are the last it got after I popped the second window. returns are coming only from PLC2 and no log file. 

[Archie]

Put a button on your form, then double click and add this code:

Code: [Select]

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        MsgBox("EnableLogging=" & ModbusRTUCom1.EnableLogging)
    End Sub

This will verify that your logging is enabled during run time.

[vitico bon]

Had problems with size. Here goes the pic.

[vitico bon]

Still not getting the LOG but I was able to get the two controllers working by bringing the PllRateOverrrite to 1000. In your test.

[Archie]

Still not getting the LOG but I was able to get the two controllers working by bringing the PllRateOverrrite to 1000. In your test.

Did you try the button test?

[vitico bon]

Yes I try the button and the Msg was "True".

I also went back to my application and increase the time to 1 second, now I can see how data return is sort of intermittent between the units PLC 1 return data for a few seconds, then switch over to PLC 2, and so on, but never the two of them, I will increase it even more to see if I reach a point where data come to both. Remember someone mentioning before that perhaps finding a way of enable/disable subscription in a fashion that the command don't go out almost simultaneously could be a solution. Obviously I have way more data in each window instance of my application than in your test. 

I also set the EnableLogging to True in my application and no data is being logged.

[Archie]

I can't figure out why you are not getting a log file. That would give me a good insight to the problem. I have a feeling the data request is flooding the PLC and it is possibly ignoring the requests. Or the required silence period between packets is not long enough. But didn't you say the same test application with only 2 values is not working for you?

[vitico bon]

Yes the same test (your test) was not working until I increased the Rate Override to 1000 then started to work. Here is the port configuration of the CLICK.

I also try increasing the rate on my app, but went all the way to 3000 and it is better but still intermittent between PLCs.

Not much to do with the log when not working it is just an enable/disable flag, nothing else, still will keep trying from time to time.   

[Archie]

Are you by any chance using a 32 bit operating system that will allow you to run Free Serial Port Monitor?

[vitico bon]

Win 7 64.

[Archie]

I'm running out of ideas since I do not have a ClickPLC with RS-485 and the logging is not working for you. I even increased my baud rate to 38400 and set PollRateOverride to 0 in order to really stress the communications. Both controllers work without missing a beat.

I even changed the log time stamp to include milliseconds to see how fast it was communicating. I'm getting about 40-60ms updates from each controller.

[vitico bon]

Well after installing the Visual Studio Express 2015 I was able to run your test and here is the DriverLog running at your original rate override of 50 As you can see it pulls from one and then after a while it switches over.

[vitico bon]

I got a analyzer demo and this is what I saw, it appears that is the program that start sending to one of the PLC then for couples of commands sent to both and then switches to the other PLC.