Industrial HMI into the future

[rec]

Hi All,

Can any of you please provide feedback to me on what operating system and programming language would be best suited for migrating from an industrial Human-Machine Interface (HMI) that presently is implemented in Quickbasic 4.5 running under DOS and must include the capability to communicate with external controllers over a serial port.

IDEALLY, we would use our existing code in QB45 and convert it to something as close as possible with serial communications capability, on a platform that uses a reliable operating system that is going to be around for awhile and on hardware (like an off the shelf Dell PC as a benchmark) that will support it.

Anyone have a crystal ball? I really want YOUR opinions.

Now before you throw your arms in the air, fingers to the keyboard and say this is so old it is absurd - a little history.

We are not a big company and produce equipment that makes thin plastic films. One of our flagship products is a multi-patented high end control system for maintaining uniformity of the finished product. The platform MUST be very reliable and stable. This control system was developed in the early 90's and has been highly successful, but hardware is becoming scarce that supports the admittedly ancient DOS. So we need to change and we have recognized this for several years now...

Enter history part II: Over the past few years, we invested several HUNDREDS of thousands of dollars ($350,000 I believe - but try not to add it up - needless to say, more than we could afford) and moved to a Windows based platform. First we used our compiled QB45 application under Win98, then went pure Windows and paid to develop a Wonderware application (a popular Windows based HMI industrial package). After that finished choking on the volume of data coming from the controllers and could not do some of the (in my opinion, simple) graphical tasks (like continuously updating graphical displays with the flood of data, polar plots, etc. - hey DOS/QB45 could do it on old machines???) we tried again from scratch with an OPC based VB platform under XP-pro...got it to do more or less what we wanted, but the developers who did the original code are not around anymore and a new (highly capable - read, they competently have the skills) group we hired to maintain it is having a VERY tough time figuring out the complexity of the code and can't believe it is so hard to sort out - it is too darn complicated! In short, it has been a total disaster and I don't want to repeat another disaster only on a yet again different road. We are starting again from scratch - we now are buying older PC's that allow us to install DOS and run the old compliled QB45 program. What is the best path forward...

HELP!

Bob

[hkdani]

What is the best path forward...

That should be doable. It would take some work and patience. But with a methodical approach, you could have a much better GUI based program developed from VB6 or VB .NET on an Intel Architecture Machine (32 bit or 64 bit processor).

The biggest problem with these types of projects is that the original programmer must have been a hater of self documentation in his program code--that's not a too uncommon trait in programmers. Get it to work. Who cares about the documentation.

Easy to say then. But now after $350,000.00, it's kind of hard to swallow by the customer.

Hank

[rec]

That should be doable. It would take some work and patience. But with a methodical approach, you could have a much better GUI based program developed from VB6 or VB .NET on an Intel Architecture Machine (32 bit or 64 bit processor).
Hank

So what is the prognosis of being able to run VB6 in the future with Microsoft playing so many games on the operating system side (ala forcing Vista on us). Do you think we will be able to stay with XP-pro (which I find decent and stable) say for the next 10 years or will they obsolete us by plan?

Let's say I go the VB way -

I did research the VB threads before I posted and found a few dealing with serial communications, but none that were terribly specific. Does VB6 directly support full control over what goes in/out of the serial ports on an XP-pro PC (like the old QB45 ON COM, OPEN COM, INPUT #1 etc.)?

How clean could I import my QB45 code into VB (4, 5 or 6)? Is it a straight forward job I could hire a grad student to do for a project?

Thanks for your feedback!
Bob

[hkdani]

So what is the prognosis of being able to run VB6 in the future with Microsoft playing so many games on the operating system side

Microsoft has commited to supporting VB6 for the next 5 - 6 years. But that's in reference to Vista. AFter Vista, I imagine VB6 is out the window.

As long as you have your copy of XP Pro and a 32 or 64 bit working machine, you should still be in business. Vb6 will work on XP Pro as long as you keep your machine running.

Does VB6 directly support full control over what goes in/out of the serial ports on an XP-pro PC (like the old QB45 ON COM, OPEN COM, INPUT #1 etc.)?

VB6 has better support than .Net 2003 for serial support. And much better than Quick Basic.

Is it a straight forward job

Couldn't really tell you that unless I saw the code. I don't know if you have all the pieces of the puzzle. I take it you're dealing with hardware that measures thickness. This hardware has to have some kind of manual that gives you the specifications on how it responds to serial communications. We call that a Software Development Kit (SDK ). If that's not available, the porter would be on his own trying to figure out the intentions of the original programmer.

That would be your main concern.

Hank

[rec]

Microsoft has commited to supporting VB6 for the next 5 - 6 years. But that's in reference to Vista. AFter Vista, I imagine VB6 is out the window.

VB6 has better support than .Net 2003 for serial support. And much better than Quick Basic.

I don't know if you have all the pieces of the puzzle. I take it you're dealing with hardware that measures thickness. This hardware has to have some kind of manual that gives you the specifications on how it responds to serial communications.

That would be your main concern.

Hank

So do you think Vista is going to be industrial accepted at some point - maybe after their bugs are worked out?

Can you please expand a bit on your VB6 comment, specifically on how VB6 serial comms commands available are much better than QB45's? Why I ask is I think I was given bad information by the now defunct software group I used - they had told me you could not take control of the serial ports (I believe they were using .NET and maybe that is why???) - and I specifically asked that question at the time, and that was the whole reason I ended up spending so much money on other approaches...beginning to sound like I was led to the end of the plank...err.

We do have FULL knowledge of all the QB45 software and the connected hardware. We design our own boards and write all the assembly code inside the connected controllers.

LOL - sounds like you may know a bit about plastic films...ie. your thickness comment.

Thanks!
Bob

[hkdani]

Can you please expand a bit on your VB6 comment, specifically on how VB6 serial comms commands available are much better than QB45's?

You just have to look at all the different properties supported by the serial port in VB6.

Quick Basic is really basic. You have to know how to access the lower levels of memory addresses to extract information from its ONCOM event. In VB6 this is greatly simplified. You can respond to feedback in the events with a wealth of properties already supplied by VB6. You can send as text, binary. You can set how many characters to receive at a shot, etc. I'm not too familiar with what Quick Basic 4.5 can do. I've done most of my serial hardware programming in VB6.

I'm assuming that your hardware doesn't give feedback over the serial port. And hence no need to respond.

I'm guessing from what you've already mentioned that you just have a few basic commands to give to the hardware and it responds and performs the desired action without responding back to the serial port?

In either case, VB6 should handle what you need to do. As long as you have the manual that states what happens when a binary code is sent to your hardware (or what binary code is sent back, if it provides feedback). The rest is just a matter of writing the VB6 code to handle what your desired goals are.

(I believe they were using .NET and maybe that is why???)

.NET 2003 left out a lot of the serial port support. To use its fuller potential in Visual Basic .NET you basically had to program it using the Windows API's Their thinking was that the serial port was being phased out. Why use it. Everybody's switching to USB.

We do have FULL knowledge of all the QB45 software

That's all a competent programmer should need. And it would be nice to have access to the hardware to work with while debugging and writing the code.

[hkdani]

Just to finish up. Most of your Visual Basic Controls are for the most part built from the Win32 API's from the Platform Software Development Kit, which are built using the C/C++ Languages.

I personally don't feel, because of the current vast multitude of hardware that depends on serial communications, that Microsoft will eliminate the Serial Communications API's in their releases of the SKD's for another 10 or 15 years by placing them in the obsolete category.

But it might be a good time to start thinking about implementing USB hardware into the picture.