HART transmitters configuration via PLC - DONE

[val_99]

Ok guys, now I may say, it is working. I have developed a project utilizing Allen-bradley ControlLogix PLC, Hart analog input module 1756-IF8H and PanelView Plus. I can view major data and perform basic transmitter settings, including range (both for analog and hart parts), zero transmitter, tag ID and damping time.
I'm attaching an image so you can get an idea of what it is.
So, my question is, would it be ethically and professionally to start offer this utility for some moderate price?. And second - would some one be interesting in such utility.

 

[widelto]

VAL_99 I´ve been working with this module for years, and Í´ve done basically the same but no graphic, your graphic is nice and I like it. I know how to get the data you´re displaying and I learned about messaging from module to hart devices, people from spectrum are very helpful. Specially Jeff Robel.
Charging for it, I think it would be better to put it as a downloadable item, anyway your effort is great and congratulation.

By yhe way your thread is duplicated, plese erase the one that is empty.

 

[Contr_Conn]

Val_99:

What is a screen uptade time?
Are you sending messages constantly or one time?
Are you using pass-through messages or predefined MSG read dynamic variables?

widelto:
This is not Spectrum module, val is talking about Rockwell module that has much easier programming than Spectrum

 

[val_99]

PLC reads dinamic transmitter data constantly, so screen update time basically defined by PLC scan time and PanelView screen update time. In my case it is 0.25 sec.
Read messages are send constantly any time this window is open.
Write to transmitter messages ofcourse send on demend (at the time when new configuration data are entered and "enter" button is pressed).

 

[Contr_Conn]

This is not what I was asking, I was asking about actual update time from the moment process value changes and this change is visible on the screen

HART protocol is very slow, so there is significant delay (seconds) between data requested and data avaliable (two separate messages).
I did not test more than two channels but I see few seconds delay at least and it will dramatically increase if more channels. It can take up to 15 seconds to process all channels for one command. it will be more if you are using more than one command.
So I just want to see results that you actually see with your testing

 

[cjd1965]

I would say sharing is reasonable if the price is very cheap, however, if you charge, maybe people will expect support.


What about making it open source for others to enhance?

 

[val_99]

This is not what I was asking, I was asking about actual update time from the moment process value changes and this change is visible on the screen

HART protocol is very slow, so there is significant delay (seconds) between data requested and data avaliable (two separate messages).
I did not test more than two channels but I see few seconds delay at least and it will dramatically increase if more channels. It can take up to 15 seconds to process all channels for one command. it will be more if you are using more than one command.
So I just want to see results that you actually see with your testing

Oh, I see now. Yes, you are right. Hart portion of data due to nature of Hart protocol are not so fast and I observed like 1-2 seconds delay, but analog portion of data (coming via 4-20 mA loop and from module status registers) basically real time with no delay.
I tryed to minimize amount of messaging while accessing Hart transmitter. But still you may see some numbers of dinamic variables coming throug hart. Practically it is working very nice, freeing myself from a need to have smart communicator in most of cases.

 

[val_99]

I would say sharing is reasonable if the price is very cheap, however, if you charge, maybe people will expect support.


What about making it open source for others to enhance?

Something like US$20.00 looks reasonable for me. I'm going to develop password protected user add-on instruction for ControlLogix v.16 to make it easier to use.

 

[Contr_Conn]

Making AOI with multiple message instructions is doable but is not very user frindly because MSG tag can't be local, in needs to be passed by reference.
As for speed you will need at least two commands per channel to get all data you posted, possibly more.
Read Dynamic Variables and Get Device Information can get you most of the data if not all, and they are fast.
If you start using pass-through messages then this will take much longer than 2 seconds even for a single channel.

But no matter how fast it works, I like your idea and the way you did it!

 

[Dua Anjing]

My two censt worth

So, my question is, would it be ethically and professionally to start offer this utility for some moderate price?. And second - would some one be interesting in such utility.

Your Time, your effort, your knowledge = possible time saving to prospective users.
If you ask me , Yes go ahead and offer it for sale, the trick is to ask for the wright amount, not to much, not to little

 

[val_99]

The idea behind this utility not even speed or fancy screen, but replacement of smart communicator. As an I&C engineer involved into a lot of designs and startups I know how it is time consuming to enter multiple parameters or check them or even zero low pressure transmitters via smart communicator. I don't want to say this utility is replacement of it, but.. it is time saver. Huge time saver and very convenient tool for everyone starting with me and ending with plant floor personal.