Modbus and Emmerson Coriolis flowmeter

[jack1]

Still having problems with the code to read an Emmerson elite CMF010 few sensor that uses the modbus protocol. I originally posted this query back in August 2008 and thought that I had cracked it but when commencing the pre-commisioning inspection it was found that the readings from the flowmeter were intermittent.

When run, the data displayed in say Temperature, will drop to zero every 20 or 30 seconds before going back to its correct value. The same thing occurs with flow value being displayed but not usually all at the same time.

The hardware connections are as follows:-

CMF010 RS485 2 wire connection to an RS485 to RS232 converter then to one of the channels on a PXI-8420 RS232 interface. This hardware setup has been checked using the Emmerson software 'PROLINK' where it worked fine with no instablity.

I then connected the RS232 output from the converter and put this directly into the PC serial port (Com 1). Interestingly the temperature and flow readings from the flowmeter now became quite stable and ran fine for about an hour before I shut it all down. In the long term this is not a solution because the PXI rack is no where near the computer (connected by fibre optic 50 metre) so wondered if I have not configured the PXI 8420 correctly?

Have attached the vi that looks after this part of the program.

[John.P]

Hi Jack,

I have been having a look into this issue for you and most of the possible problems have been discussed in you previous posts on this topic, however a few things spring to mind.

In your code your are filtering out error codes for things such as framing and parity errors, do you still receive these errors when you are connected directly to the PC COM port, or are these only appearing using the PXI hardware?

It appears the code will run the Blank state and then re-run the initialize state once an error is received, I would guess it is this causing the incorrect readings.  Can you confirm this?

I would suggest adding an LED to your front panel and apply a true to this during the "Blank" state.  If the LED comes on at the same time the readings drop off then the problem is been caused by the re-initialisation of the port whilst the program is running.

Also are you using an embedded controller in the PXI or using the PC as the PXI controller?

Hopefully this will allow us to narrow down the problem.

Best regards,

John P

[jack1]

Hello John

Thanks for reply. Sorry for delay in reply but the equipment is now in a different location to where I am so having to create file, email and get reply from tech on site until I go out in February.

Originally the code was run by just monitoring the serial modbus but after a few minutes the front panel readings for temperature and flow stopped. Using a front panel LED (similar to your suggestion) this occurred when the error code was generated and despite an attempt to trap it this failed and the port no longer appeared to read the serial data. So as a 'brute force' attempt a mod was done to make it re-intialise. I have sent this part of the code out again with LED on front panel and re-initialise removed, tech confirmed that after error code is generated the code no longer gives a flow or temperature reading.

The PXI rack does not have an embedded PC as controller but uses MXI PXI/PCI fibre optic boards. The other DAQ boards / functions work fine (mix of 65 channels of CTC, Analogue and Digital) its just this one which is the only serial connection being used. When the serial / modbus aquistion is taking place the software is logging 14 analogue channels in loops that update every 400 ms and controls an engine in closed loop via counter channel with analogue postion feedback.

Errors were not noticed when the serial / modbus aquisition was taken through the PC's own serial port. When I first was trying to get this set up to work I had errors when just trying to communicate with the flow sensor, no other DAQ was running at that time.

Thanks Jack 

[John.P]

Hi Jack,

Thanks for the reply.

At this stage I think there are two ways to approach this problem.  We can either try and find the cause of these errors and stop them occurring, or we can attempt to change the error handling to try and better compensate when they do occur.

The framing and parity errors are generally due to serial port settings with unmatched properties, lack of timing delays, or noise.

Can you check the serial port settings in MAX are set to the expected values?

Have you tried using a different port on the 8420?

This KB has some additional information on the framing error.

A 6101 error is a modbus timeout error, usually due to a large number of registers been read on a single read.  The timing setup on your VI appears to be fine and it does not appear that your are reading a large number of registers so at this stage I am unsure as to exactly why this could be occurring.

In terms of modifying the error handling I found this forum post where it was suggested that reading in a loop until no errors occurs is a way around the 6101 error.  This kind of setup could also catch the other errors and potentially solve this issue.

However I am unsure as to whether this will work in your case, it depends whether once an error has occurred all subsequent data is corrupt until the port is reset.

Have a look and let me know what you think / how you get on.

Best regards,

John P

[jack1]

Hi John

Thanks for the links.

I did try swapping over channels at the time and still got the same results so assumed that the hardware buffers were ok but unsure if there is a common controller IC on the DAQ board. So have ordered and had delivered yesterday a PXI RS485 Dual channel DAQ card so it will be 'belt and braces' in February.

In the meantime I looked at your links and the first thing that jumped out is missing the tunnel for error, resulted in the acquisition stopping. When I looked back through my notes that was the reason, on an error I jumped to Blank case statement and then waited before restarting the acquisition. Sitting here in peace and quite I accept it is really rough, but was on site at the time and under pressure.

Modified the loop now to a tunnel for the Error so hopefully that will cure the problem of the acquisition stopping after an error code, although it was trapped.

Looked at the other link and its quite neat where the loop trys 3 times on error and then drops out or gets valid data and runs, so will look at that tomorrow.

Because the MAX settings is on my clients computer (and in a different country) I cannot check at the moment,  but looking at my notes for settings used originally they agree with Labview code and have also written notes that these were rechecked numerous times when I was first trying to get the system running. Can only assume at the moment that these settings are correct, but will check.

If I assume that settings in MAX are correct and the RS232 DAQ board is Ok why would I still be getting the Error codes -1073807254, -1073807253 and 6101?

I think what you are driving at is that these errors should not occur, and I agree. The electrical connections from the Flowmeter is approx 3 Metres and all self contained on the data logging rack so no external interference. Usual EMC installation requirements have been observed and all power supplies on this system (apart from the PC and unknown what the PXI rack uses) are Linear. When I was first developing this part of the project and was having problem the data frames for the PROLINK software and my Labview attempt were 'grabbed' and compared. there were differences in timing between the frames and I contacted Emmerson but hey said it was fine and would not cause a problem. But I still got these error codes, which as you point out are timing and framing errors.

Thanks for your help John, appreciated

Jack

[jack1]

Hi John

From your links and another that I found have implemented the following. Because I have not got any Modbus equipment here I cannot check this until I am at my customers at the beginning of Feb so outcome is unknown, but will post results after then in case anyone else is interested.

The code I posted earlier has been modified as follows.

In an attempt to remove error -1073807254 and -1073807253:- 

After the intialisation case a further case statement has been added to introduce a 1 Second delay, this should allow time for the serial board to set its self up and then to flush the DAQ boards buffers using Visa vi 'Flush Buffers'.

Regarding error code 6101:- 

Looking at my notes from earlier work the reason I went to the Blank case statement, waited and then re-intialised the serial board and then went to read case statement was that if I had an error (even though I was trapping them) the modbus acquisition would stop and no longer work. So I assume that the recommendation from Ravens Fan (your link above) regarding Errors needed implementing? Therefore I removed the shift register for Error and replaced with Tunnel. Tend to use shift registers with the Error wires because I usually use Case statements in most of my code.

Using a Tunnel though, if an Error occurred in say the intialisation case surely this error would not now be passed to my next case statement? Also I would have thought that as I was trapping specific errors they would not stop the modbus acquisition although they seemed to?

Implemented the 3 attempts loop also.

When I get to customers site in February I will try out this lot with existing setup. If still having problems will try a different RS323 to RS485 converter and then as last resort replace the PXI RS232 card for RS485 PXI 8431. Spoken to Emmerson this morning and all they suggested was to check the termination resistors, which has already been done so nothing new there.

Thanks Jack

[John.P]

Hi Jack,

Thanks for the update.  It sounds like what you have done with the code will hopefully resolve the problem.  Your current plan sounds like a good one, test the new code with the hardware and let me know how you get on.

Thanks for keeping me updated and good luck with it in France.

Best regards,

John

[jack1]

Hi John

Wished it was France, nice and easy but not this time itsTurkey. Will let you know outcome,

Cheers

Jack