fieldgate_dm3_reporter is an open-source GPL’d utility, written in pure Python (version 2.5 or greater required), compatible with Linux / Unix / Windows / etc. etc… that allows you to gather data from existing MySQL databases, and export it via email (SMTP) in XML format to an Endress-Hauser Supply Gate DM3 server.

Until now, most persons were faced with duplicating their data gathering… one set of sensors for their internal storage or device monitoring (whether it be inventory, levels, temperatures, whatever…) and one set for reporting to their supplier via E&H’s DM3 servers.  Or, in the least, 2 sets of transmitters, or an RTU (real time unit) attached to their existing sensor array(s).

Now, provided your telemetry is stored in tidy MySQL databases (as it should be if you’re using mod_openopc and S.E.E.R. to automate your operations!!) you can snapshot the current database values and export them to E&H’s servers… all in software.

Once you’ve setup the program (via the ‘options.opt’ global settings file), you can simply call it as a scheduled task (via Cron in Linux or Task Scheduler in Windows), every few hours, or every few minutes (whatever you desire).

You can download the latest tarball here… http://download.spinellicreations.com/fieldgate_dm3_reporter 

So after 6 months of rebuilding, System and Environment Effective Reports has sprung back to life.  Internally, it’s live in Active Production, running 24-7, and doing wonderfully (I’d stand for nothing less).  Publicly, the active subversion snapshot as of May 24th, 2010 is offered as a Pre-Release.  It’s stable, tested, and modularly complete.

You can download the Pre-Release here… http://download.spinellicreations.com/seer/

Docs are included, however, they’re sparse as of date;  global and local options are stashed in the ‘./config’ subdirectory, and must be edited for both the system and the individual System Models.  Each model will also have its own global and local options files.

Primarily that’s the reason why it’s not called a full Public Release — the full User Documentation has not been written yet.

Be advised, if you’re using S.E.E.R. and mod_openopc to perform a significant amount of I/O or comm, then you’ll need a suitably robust server to run it on.  mod_openopc / S.E.E.R. system requirements are as follows…

ABSOLUTE MINIMUM -

– Architecture - i386

– Host Operating System - Red Hat Linux (or variant) v. 5-2 / Fedora 7 Moonshine 32-bit

– Guest / OPC Operating System - Windows XP Pro SP2 32-bit

– Processor -  2.0 – 2.2 GHz AMD Athlon Thunderbird / Barton or 3.0 GHz Intel Pentium 4 Single Core
– Memory - 2 GB DDR PC3200 400 MHz
– Disk Space - depends on the size of your database (how much data you wish to store). Plan on no less than 1 GB per machine per year of retention, at an absolute minimum. Your mileage will vary greatly. (1,000 tags yields about 3 gigs per month - again, this is all relative).

SUGGESTED PLATFORM -

– Architecture - x86_64

(note: this is for the host OS, your OPC Server should reside on a dedicated 32- bit machine, or in a 32-bit virtual machine within your host OS. This is for OPC Automation compatibility assurance).

– Host Operating System - Red Hat Linux (or variant) v. 5-4 / Fedora Core 11 Leonidas 64-bit

– Guest / OPC Operating System - Windows Server 2003 R2 32-bit

– Processor - 2 each – AMD Opteron 3rd Generation Barcelona Quad Core @ 2 GHz or better.

– Memory - 32 GB DDR – 800 Mhz ECC Registered Server Memory

– Disk Space - depends on the size of your database (see above).

– Virtual Machine - at this time, we are recommending Sun Virtual Box, as VMWare Virtual Server is no longer supported under newer Linux / Unix releases due to new glibc builds and the decision by VMWare to phase out Virtual Server Free Edition. Sun Virtual Box is easier / faster / and ultimately better suited anyway (in our experience)… and it is also freeware.

After nearly 7 months of rebuilding (from almost ’scratch’), mod_openopc once again breathes life into the world of OPC driven HMI / Scada / Historian applications.

The Open-Source, Open-Standards, “Free as in Speech and Beer” solution, based upon Barry B.’s Open OPC for Python ( http://openopc.sourceforge.net ), sharpens its teeth for the next go-round.  With new, fully-cross-platform, portability (Windows / Linux / Unix / BSD / fun-fun-fun); more functions than before (Space Bridge / Read and Write Daemons / Database cleanup and optimization); and nearly 13,000 hours of equivalent torture testing; we proudly announce the unofficial public release of version 3.0-11 (build # 37 -April 12, 2010).

You can download it here… http://download.spinellicreations.com/mod_openopc/

Pick up the user manual and all the docs there as well.

… and for anyone wondering about S.E.E.R. version 2 — it’s ahead of schedule by nearly 6 weeks, with more interoperability and functionality than version 1; look for it around June, this summer!

- the admin.

The question of “To ground - or not to ground” (with regard to Low Voltage Transformers) has been one that’s plagued me for a bit now.  Apparently, I’m not the only one with this on his mind. I’ve not been lost in the dark (at least not completely), as it’s been more a matter of isolation that’s my concern.  That said, some people are completely “out to lunch” on this one…

I found this interesting little tidbit of back-and-forth on the ‘net…

http://www.flukecommunity.com/forums/showthread.php?t=2475&page=3&pp=10

As it seems, yet again, MikeHolt.com appears to be one of the few world-wide-webbers with any sense about him…

http://www.mikeholt.com/technical.php?id=grounding/unformatted/9-15-99&type=u&title=Grounding%20-%20Machine%20Tool%20Transformers%20(9-15-99)

Mike’s absolutely correct.

Bonding the transformer’s secondary side “Neutral” (whichever pin you declare as neutral, since nothing has been referenced to ground yet) to Earth Ground (via any good solid connection to either machine chassis [assuming machine chassis is bonded to Ground] or by simply piggy backing onto your supply voltage Ground) is the only way to go.

It’s not a Code violation - believe me, it’s not.  The whole idea behind not bonding Neutral to Ground at subpanels (or in any panel besides the main service panel entrance / feed panel / whatever it is, depending on whether we’re talking 240 Residential Split Phase / 480 Vac3 Commercial / on up through Industrial power) is that you don’t want to create a ‘loop’ in the system.  There’s 2 reasons for that.  First, a ground loop can actually build its own voltage potential.  That’s hell on earth waiting to happen.  Second, your grounding conductor is no longer isolated from your neutral conductor, which means that in an emergency it will not have the capacity to carry the system’s full brunt to ground.

However, with a transformer, the secondary side is ‘virgin territory’; remember, the primary is fully isolated from the secondary, and voltage is only induced upon it.  No current physically travels from the primary to the secondary.  That said, there exists no path to ground for the secondary side… you have to create it by bonding one leg of it to ground.

Mike cites Article 250, Section 20, and I’ll add to it with this… unless you are dealing with a 1-to-1 isolation transformer, whose sole purpose is to completely isolate the system from the supply, then ground whichever leg you declare to be neutral to supply side ground.  Watch our for current carrying capacity though… a 14 awg line feeding a 480 panel that’s only eating up 10 amps, with a 20 amp 120 Vac (secondary) transformer will require you to increase the size of the feed line’s grounding wire in order to comply with the restrictions of Article 350 regarding maximum current flow through a conductor.

In the event you do not fuse a transformer (or power conditioner), then yes you should fuse all legs.  This should go without saying.

So, it’s been up for a few weeks, about time I posted a picture or few.

Server project Launch Re-Loaded; PentiumSlayer1, PentiumSlayer2, and StorageSlayer.  I’m a brownout waiting to happen.