ModBus RTU Parrallel Programming

[gfulk]

Hi Archie,
We at my company love your product and have adapted some of our HMI programs to use this product and the capability of .NET.  I am working on an application utilizing the Modbus RTU Driver in c#.  I am using a task to read the registers currently something like this.

Code: [Select]

try
            {

                System.Threading.Thread.Sleep(75);
                lock (_MyModbusCom)
                {
                    preCompactionReading = Convert.ToDouble(_MyModbusCom.Read("L40001", 1)[0]);
                }
                while (recording)
                {
                    lock (_MyModbusCom)
                    {
                        LiveCompression = Convert.ToDouble(_MyModbusCom.Read("L40001", 1)[0]);
                        CurrentSetpoint = _MyModbusCom.Read("L40013", 1)[0];
                        if (!SPReached)
                        {
                            PeakCompression = Convert.ToDouble(_MyModbusCom.Read("L40007", 1)[0]);
                        }
                        else
                        {
                            preCompactionReading = Convert.ToDouble(_MyModbusCom.Read("L40001", 1)[0]);
                        }
                        Dosing = Convert.ToDouble(_MyModbusCom.Read("L40027", 1)[0]) / 10;
                    }
                    System.Threading.Thread.Sleep(50);
                }
            }catch(Exception ex)
            {
                throw ex;
            }

This is the inside of the Task that reads the Modbus registers. These values get used for data visualization but I am having an issue where in the middle of execution I get an error stating "No Response from PLC, ensure driver settings are correct". I know my driver settings are correct. I would assume this is because I am "Overloading" the read/write capabilities of the driver/hardware(RedLion PAXCDC4 MBRTU card). I don't know if the lock statements are causing an issue but I am monitoring the class properties from another task here:

Code: [Select]

System.Threading.Thread.Sleep(250);
            while (recording)
            {
                var cp = PeakCompression;
                System.Threading.Thread.Sleep(50);
                if (PeakCompression < cp)
                {
                    SPReached = true;
                    _EventAggregator.GetEvent<SetPointAchievedEvent>().Publish(cp);//Publish setpoint reached event with peak compression as its payload
                    //IsEjecting = true;
                    while (SPReached)
                    {
                        postCompactionReading = LiveCompression;
                        if (IsEjecting)
                        {   
                            Ejection = Math.Abs(postCompactionReading - preCompactionReading);
                            _EventAggregator.GetEvent<EjectionAchievedEvent>().Publish(Ejection);
 //Publish ejection event with the ejection force as its payload
                            lock (_MyModbusCom)
                            {
                                preCompactionReading = Convert.ToDouble(_MyModbusCom.Read("L40001", 1)[0]);
                            }
                            //SPReached = false;
                            IsEjecting = false;
                        }
                    }
                }
            }


Here I am monitoring the values so I can step into the next part of the process. I was looking into the BeginRead() method that returns an int value, I had planned on breaking that apart and looking at the individual bytes in the int, but they returned all 0's. If you have any advice on parallel programming with the Modbus RTU driver and the best ways to return these values it'd be appreciated.
Thanks

[Archie]

I would probably start with setting EnableLogging to True and check the driver log file to see if indeed the device is not responding.

The driver should not have a problem with multiple thread access because every request goes into a common queue and they are sent out one a time as each response is received.

The Read method uses BeginRead, but then blocks until a response is received or timeout. BeginRead does not block, so if you use BeginRead, you have to assume the responsibility of not sending requests faster than the device can respond because it will overflow the queue.

[gfulk]

I enabled logging and didnt see anything out of the ordinary. We are starting to err on the side of this being a hardware problem due to inconsistencies between machines. Thanks for the response though!

[Archie]

In the log file, did you see any requests without corresponding responses?