My totalizer is off by app. 2000 or 3000 lbs most of the time

The software is Snap Pac Pro, the controller is a SNAP-PAC-S1 and the brain where the Analog module resides is an
EB1. The signal comes from a new Emerson Mass flow meter that checks out good. For some reason after loading out
a railcar the weight of the car is off by app. 2000 or 3000 lbs. We load 194000 lbs. at a rate of about 1200 lbs/min.
Is there a problem with my script or could there be issues with communications between the Controller and Brain?
The sample was going negative at startup so I added the script that zeros the sample at start. I might add the
Controller has a very large program running on it. Any advise would be appreciated. Here is the Script:

//Get Totalizer Value
if (ai_Pan2_Product_Flow > 2.0) then
SetAnalogTotalizerRate(f_Pan2_Rate, ai_Pan2_Product_Flow);
f_Pan2_Sample = GetClearAnalogTotalizerValue(ai_Pan2_Product_Flow);

            if (f_Pan2_Sample < 0.0) then
               f_Pan2_Sample = 0.0; 
           
            endif

             f_Pan2_Sample = f_Pan2_Sample / 60.0;
             f_Pan2_Totalizer = f_Pan2_Totalizer + f_Pan2_Sample;

endif

//Reset Total display value when n_MMI_OPPan2_Reset = 1
if (n_MMI_OPPan2_Reset == 1) then
f_Pan2_Totalizer = 0.0;
f_Pan2_Sample = 0.0;
endif

// Return Reset to 0
if (n_MMI_OPPan2_Reset == 1) then
DelaySec (2);
n_MMI_OPPan2_Reset = 0;
endif

Hi Markjuan1, quick question while a few others get a chance to look at your question and chew it over…
If you jump onto PAC Manager and look at the memory map address for the analog channel, do you see ‘sane’ numbers there?
You can do this while the strategy is running… you will need to click ‘Refresh’ to get the data to update.
Reason I ask this is that if this number is not doing what you expect, then can at least eliminate your OptoScript as a possible issue.
(The old saying, ‘garbage in, garbage out’ is what we are checking for here).

Hey Ben,

Thanks for responding, but I just got word from our Production Supervisor that the Totalizer is correct after all. It was operator errors in the end. Sorry for wasting anyones time, but they argued over this for a couple of weeks. I felt I needed to cover my behind. The memory map looks good to me. I’m still open to any critique of my script though. I’m a rookie at this and always open to suggestions.

Thanks, Mark Farmer
OPTO Class of April 2009

Correction: OPTO22 Class of April 2008

Hi

When you say 2000-3000 lbs “off”, can you confirm that this is below the real quantity and not above. I presume you are checking this with a weighcell.

I am not being funny, but please check your Emerson Mass Flow meter input to the Opto systems. Emerson s Micro motion Mass flow meters, based on the Coriolis effect, are great when set up, specified, installed and calibrated correctly, and do not suffer from air bubbles etc. Probably the best in the market.

Unfortunately many of the “experts” who sell or commission them do not actually know what they are doing, with the end result that the instrument never measures correctly and you can spend a lot of time and money in figuring this out.

How to decide if the problem is in the Opto part of the court?

a) Check what the MassFlowMeter is reporting as totalized compared to your weigh cell and that the instrument is calibrated correctly. You may just find a surprise! ( I assume your weigh cell is calibrated!).

b) Compare your totalized value against that stored in the meter. Also compare against the totalized value as stored in the meter. You can configure the instrument to display the total on screen or through a PC with a suitable adaptor. If you suspect your MFM is not actually measuring properly, you can always measure a fixed quantity into an oil drum and then go and weigh it. MFMs are to measure mass not volume.

Generally engineers tend to put blind faith in MFMs from Emerson. I have had many surprises over the years when someone realizes that the meter is not actually working properly. As I said previously, this should be detected during commissioning, but with what Emerson charge per hour, everyone is usually in a hurry to get the instrument signed off!

Assuming that the MFM is set up and operating correctly, Check to see how accurate your totalizer is. Connect a digital calibrator to send 20mA signal into the SNAP-AIMA module and your totalizer function for one minute to simulate the MFM. Doing the maths you should be able to see how accurate your totalizer function really is

Regardless of the results, I would not recommend your implementation. You have a natural conversion error created by converting the flowrate to an analog 4-20mA signal in the MFM. The 4-20mA is more suited to flow rate display, the precision comes from using the pulse ouput. You then have another conversion error in the SNAP-AIMA module, both from A/D precision and input scan time. There is another time issue in polling the module from the EB1 brain and the biggest time variable of all is the transfer across an Ethernet network in order to get to the SNAP-PAC-S1 controller. Inside the SNAP-PAC-S1 controller you have a multitasking chart environment that does not guarantee a fixed scan cycle. For most applications you will never notice the difference, but unfortunately tanker loading is not one of them.

As stated, I would not actually recommend using the 4-20mA analog output from the mass flow meter. Go digital! Use the pulse output and count every single pulse. The suitable module is a SNAP-IDC5-FASTA module, and calibrates the meter to give you somewhere between 8000Hts and 12.000 Htz for maximum flow rate. The SNAP module can handle this fine. The idea is to give you a pulse for every lb ( or less!) and you will count every pulse.

You can use the counter function supported on the EB1 brain to count the received pulse. You can also use the Digital Events function also supported on the EB1 brain to provide precut value and final cutoff output contacts. Maybe even add some inflight compensation based on product and source. You just need to monitor this from your chart running on the SNAP-PAC-S1.

This is a classic example of programmers doing real time control programming from a centralized single threaded program, without using any of the benefits that Opto22 hardware offers. Opto22 was invented, to offload real-time processing from your main strategy program to the local I/O processors. It’s not how programmers think, but the benefits are there. Opto has implemented most of the real time functions you need in the BIOS of the EB1 processors. Functions such as counting actually save you time and work, making your programs simpler. If you find there is not enough functionality in the memorymap BIOS you could always upgrade the EB! Processor to a SNAP-PAC-R1 processor and implement more functionality locally, to avoid the needing to poll from the distributed SNAP-PAC-S1 processor across TCP/IP.

Ben,
Thanks for your reply. We found the problem. It was operator error. The railroad made some changes that caused the operators to measure from the wrong place. Long story, anyhow I learned a little more about PAC Manger from your reply. So it wasn’t a total waste of time.

Thanks, Mark Farmer (OPTO22 Class of April 2008)