Hello Folks,
Since mscomm.ocx for some strange reason will pop a license block unless you also install VB Professional (which most people don't need) I am looking for other methods to communicate with RS232 from Excel VBA, other than directly using the API. Lots of Google searching provided only one alternative, a routine called "cheapcomm". However, none of the download sites from back then (2004 and earlier) works anymore. Does someone know a site that still has it?
-- Regards, Joerg http://www.analogconsultants.com
warning: a lot of special magic stuff of this kind is totally broken by modern Office versions. Our helpful IT people installed another
512MB RAM in my office PC a few months ago, and since they were there anyway they "kindly" installed the latest version of Office. Presto - everything is broken, starting with my HP oscilloscope communications software [which was an ActiveX Office plugin] and all the way down to several custom data capture applets.Moral: don't necessarily expect that it's going to work even if you find it.
So, do you think it's better to go through the parched lands and directly via the API then? Mostly it'll be through virtual COM ports over USB.
MS seems to really start lagging in terms of backward compatibility. When installing .NET 2.0 the Instek oscilloscope comms would not work. Installing 1.1 fixed it again.
-- Regards, Joerg http://www.analogconsultants.com
mscomm32.ocx is often a headache. The only sure way is to install VB6 (I a not sure if you need the professional or enterprise editions for th registration to occur). You can in fact uninstall VB6 immediatel afterwards without ever having used it, and the registration will stil stick. I guess you could do this with a borrowed copy without violatin the copyright.
However there is another alternative described here
I have only been told of one case where this did not work, and I am no certain that it was indeed a problem. Try it and see.
I describe using mscomm directly from Excel in two of the chapters of m book
Excel by Example: A Microsoft Excel Cookbook for Electronics Engineers published by Elsevier/Newnes ISBN-10: 0750677562 ISBN-13: 978-0750677561 and available from most booksellers on the Internet.
-Aubrey Kagan
I fail to see any reason for anyone to put up with these shenanigans. Linux is still available, at a reasonable price, with a reasonable license.
-- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems.
What has that got to do with the OP's question? Why is it that linux bigots can never answer the question, but rather just dodge it with some completely irrelevant drivel. If Joerg wanted to use linux, then Joerg would have used linux because Joerg is more than competent to do so, but that is not what was asked.
To deal with the original question, the mscomm ocx can be used if the application is packaged, but unfortunately you will need a copy of VB to do this. The other solutions is to track down the registry key that mscomm uses to validate itself buy using a regmon (sysinternals) or whatever the new version is called.
Failing all of that, then you can use the win32 api, but this would be a pain in VB if you don't have a great deal of interfacing with the API.
Right, no Linux here. This has to work on client's PCs and their IT staff would roll on the floor holding their bellies if I suggested they change out the OS on a number of PCs.
On a side note Linux seems to cause some quirks in cooperation with Windows systems. For example, when I want to unzip a file that resides on the Linux-based LAN drive here I usually receive the error message "not a zip file". After moving it over to a Windows PC the same file unzips just fine.
That key is given in the link Aubrey posted. However, I am not sure whether this method is fully legit from a copyright POV. At least I could imagine that some IT guys would raise an eyebrow and decline to do that. Usually those are the folks who would have to do a registry edit in many companies.
I looks like it does boil down to using the API. Certainly not something to look forward to :-(
VBA within Excel is such a great idea. Why did they leave it lacking so much in connectivity? MS could sell a whole lot of copies for lab and production PCs if it wasn't so difficult to connect hardware. Right now everyone defaults to LabView, DAQFactory and SW like that, or they just don't do anything at all if the expense isn't warranted.
-- Regards, Joerg http://www.analogconsultants.com
I would never have made the comment in another newsgroup, but this is c.a.embedded, and I fail to see any reason for Windows fragilities to impede things.
On this, I suspect either your unzipper or that you have had some file transfer problems. Line endings are stored differently on Linux and Windows, so the copy mechanism has to take steps. Zip files are binaries, and those steps should be inhibited. For reliable standard zip packages go to infozip.
-- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems.
Sometimes you must put up with it. The installed base is huge. Other times you have to do it because the customer wishes it. For example, we have desigend a whole big ultrasound machine around Windows (after tossing an re-writing a lot of stuff). Ok, it's big, about the size of a small dishwasher but that's an embedded application.
Sure, but the drive is marketed for Windows-based networks. However, no complaints because other than that it works nicely. Made it very easy to send off a scope screen capture from the lab. The USB extension was thoroughly botched by the mfg though.
-- Regards, Joerg http://www.analogconsultants.com
Hi Joerg,
Have you discounted the WindMill drivers ? They work with Excel.
LabIML 4.3 is the ASCII-only version which is free for the cost of signing up for their newsletter. I've been on their list 4-5 years and although one can quit after the download, I haven't. Very little traffic and what there is sometimes even useful. You have to pay for the binary version.
HTH ... Marc
Marc_F_Hult
Thanks, I did look there. Unfortunately what comes off lab equipment is pure data, not ASCII :-(
GBP145 times number of seats just to get data from RS232 into Excel is a bit steep.
-- Regards, Joerg http://www.analogconsultants.com
Hi Joerg, What about designing a small single chip 'lab equipment format' to ASCII converter? Can't be more than a few $ per seat. Rocky
Joerg,
I am ashamed to admit that I don't know if the latest versions of MS Exce use VB.net. VB.net (at least the free version VB2005 Express) does no support use mscomm, but has its own serial port control which does no appear to need additional registration. The control itself is lacking in few features, but if Excel now uses VB.net this could be your answer. Fo what it is worth I wrote an article on VB2005 Express and the Serial Por in the December 2006 issue of Circuit Cellar (issue 197).
Actually, I am not sure what you are trying to do. You could turn you approach around and create your application in VB.net and then contro Excel from VB to achieve your ends. The above article was actually part o a series in which I created a Modbus interface using the above approach The series was completed in issues 200 and 201.
-Aubrey
I am not a fan of .NET. It seems to have serious backwards compatibility issues. Case in point: New scope SW came, must have .NET. Installed 2.0, did not work. Inquired -> Must use 1.1 because 2.0 is not compatible. Great.
What I am trying to do is access instruments via RS232, mostly through a virtual serial port on a USB connection. But it has to run at other places and many are using older Excel licenses. So it has to work all the way back to '97. It is possible since several instrument makers provide exactly that. However, their SW is not open and so it cannot be adapted to any instruments other than what they are selling. Technically yes, of course, but it would violate their copyright. I guess they are going directly via the API.
-- Regards, Joerg http://www.analogconsultants.com
Yes, but then you have to run up a small production and all that. Not quite what I wanted to do ;-)
-- Regards, Joerg http://www.analogconsultants.com
You're missing the point entirely. For the first significant time that MS has done it, you can have all 3 versions of the .NET runtime installed at the same time without them interacting, and whatever products or components you install get the same version isolation. It takes more disk space (though not that much, it's only 40Mb or so), but it does avoid DLL hell.
I've heard this whine from you multiple times, presumably all relating to the single occurrence, but it was *your* mistake because you installed the wrong version. Perhaps your supplier didn't give you enough info, but that doesn't make it MS's mistake.
You should be congratulating MS for finally doing something positive about solving DLL hell, not castigating them for your mistake.
Clifford Heath.
That appears to be Microsofts latest approach to solving version dependancy issues. Just run a separate copy of every version. So if you have a program using version 1 and another program using version 2 you get both copies in memory.
It appears they've given up on the idea of actually getting it right. I don't know if it's a reasoable approach but it sure rubs the wrong way.
Just in case you were wondering why disk and memory requirements keep climbing w/o bound.
Robert
-- Posted via a free Usenet account from http://www.teranews.com
40MB to get to the ports, wow ...
I've heard the same whine from hardcore SW guys, except that some of them used words I could not repeat in public.
Your are probably right. However, that's a "version control" scheme that is totally foreign to me. And I bet in my line of biz (FDA regulated) the Federales wouldn't let that fly. With our SW newer versions must support the old stuff. Just imagine the ER doc loading a patient file because he urgently needs to get some info, then a message pops up "Requires DICOM version x.xx, please contact your IT administrator".
-- Regards, Joerg http://www.analogconsultants.com
ROFL! That was a good one. But it sure looks like it. Now if it was only .NET that would be one thing. The world would keep spinning without it. However, it seems there is now an "oh s..t" experience even with Vista.
Anyhow, I have become very careful WRT adopting all this newfangled stuff from up there. Ordered a new desktop today. With XP. Surprisingly the sales guy at the small biz desk told me right off the bat before I had even brought it up "And you want XP on there, right?"
It's not that I am dissing MS for everything. They did produce some nice and useful SW packages. Office being one of them, but also MS-Works.
Bloat without bounds. Funtionality doesn't grow in proportion though. This whole problem with RS232 into spreadsheet was a non-issue in the DOS days. I used MS-Works. It had a built-in terminal program that could pipe in the data, a spreadsheet, a word processor and a database. So when I wanted to recreate and decode a datastream out of my logic analyzer (to diagnose ADC distortion effects) I grabbed a serial cable, plugged it in, and bingo. No .NET, no Active-X, no DLL hassles. It simply worked.
Heck, if I have my druthers one day I may just go back to that MS-Works program. It's still here, on a 5-1/4 floppy. I wonder if the COM ports can be addressed from a DOS window.
-- Regards, Joerg http://www.analogconsultants.com
Getting to the ports might be all *you* wanted, but the runtime provides an entire JIT compiler-interpreter and its runtime library, i.e. it's an entire platform, and actually quite small for what it is.
So you'd expect that old DOS program to still work under Vista, would you? Myself, I'd rather that the platform moves on occasionally, and that means breaking compatibility with programs that depend on bugs and design flaws in the old version. At least with .NET you have the option of running old programs on the old runtime, and new ones with the new one. It's not as though they've released hundreds of versions, after all - there are only two in play currently and a third coming.
Clifford Heath.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.