Messages posted by: mlohbihler

Do you find Mango useful? Do you want it to get better? Do you want to help?

The easiest way you can help out Mango is to let others know what you think! Please link to Mango from your web site. (Use logos and such if you like too, and link to http://mango.serotoninsoftware.com.) Or, write a short description of how you use Mango to put on our home page.

The more people there are who use Mango, the more it will be developed and improved.

Thanks!

Hi Abhijit,

That depends upon how your devices can receive data. There are two possible approaches, both of which require coding in Mango to implement.

1) Put a payload into the response to the HTTP request. When your equipment sends data to Mango, any messages that you wanted to send to it get queued, and returned in the response. This solves a great deal of internet routing issues and makes DHCP usage irrelevant, but means that field equipment needs to check in regularly for any queued messages, and so is not the most efficient use of bandwidth.

2) Send requests back to the field equipment from Mango on demand. This approach means that your field equipment needs to be accessible over the internet and listening on some known port for incoming messages. Additionally, Mango would need to know how to structure the message content so that your equipment can make use of it.

And for software see www.opcfoundation.org, there seem many servers and clients for demo available???

That would be what i was referring to:

I know there are some sample servers on the internet, but those i've found so far contain a single unchanging point. Not very useful...

Because i like how it looks?

I haven't written any code yet. There was no point in starting without decent equipment to work against. You have some OPC XML-DA stuff? Any chance i could hit it up for a bit? Could you open just to a particular IP address?

If anyone has access to hardware it will speedup development.

Isn't that always the problem! I might as well make a shout out now for OPC XML-DA hardware. If anyone has any that they can make internet accessible for the purposes of data source testing, please let me know. I know there are some sample servers on the internet, but those i've found so far contain a single unchanging point. Not very useful...

Are your data sources completed/tested? You did mbus and openv?

See the s/getValue methods in ModbusMaster. You can provide the slave id directly or use a ModbusLocator to encapsulate register details.

When you create the TCP master you have to provide an IpParameters instance. The host value is the IP of your slave.

Annotate your class with "@JsonRemoteEntity". The JSON serializer is picking up the s/getAlarmLevel from the super class.

Perhaps posting your source would help.

JFreeChart supports multiple scaling groups, it would be handy to draw values that lie in a different range onto the same chart with different scalings.

Some sample code would go a long way to getting this included in Mango.

I encounter some funny charts where a value chages drastically in a short term (it jumps) and was before for a long time very stabel. Instead of a steep acend I get a slow.

That is a very typical way of representing the data in a chart.

Solution: If a value changes store not only the actual changed value but store as well the last value of the stable sequence.

"if/then" logging code like this complicates the matter quickly, and often has disconcerting unintended consequences. Overall, I'd be very hesitant to start logging data values that were not actually received from the data source.

BTW, did anyone try this out?

Speaking of which, what happens if the data source is restarted? Do you get the errant number?

I.e. stopped and started.

Actually, the second option as Craig described is much easier to implement than any other option discussed. It is also much easier to understand for the user.

Jokke, your option #2 is intellectually interesting, but i'm not sure of the actual practical value of it. It assumes that the equipment from which you're getting data is highly prone to error, in which case i'd suggest getting better equipment. If you have a real life example of where something like this would be necessary, please describe.

On the other hand, equipment that has particular (and predictable) startup value - like 85 - is conceivably common, and so i've implemented an optional min and max range for the next version, outside of which values will be ignored.

Oh, i also added audio and graphics to cached directories.