Excel-RS232 via Cheapcomm: Where?

Marc_F_Hult wrote:

> On Wed, 19 Sep 2007 15:05:22 -0700, Joerg
> <notthisjoergsch@removethispacbell.net> wrote in message
> <A%gIi.4992$Sd4.1737@nlpi061.nbdc.sbc.com>:
> 
> 
>>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?
> 
> 
> 
> Hi Joerg,
> 
> Have you discounted the WindMill drivers ? They work with Excel.
> 
> http://www.windmill.co.uk/rs232.html
> 
> 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.
> 

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

On Sep 25, 10:45 pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> Marc_F_Hult wrote:
> > On Wed, 19 Sep 2007 15:05:22 -0700, Joerg
> > <notthisjoerg...@removethispacbell.net> wrote in message
> > <A%gIi.4992$Sd4.1...@nlpi061.nbdc.sbc.com>:
>
> >>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?
>
> > Hi Joerg,
>
> > Have you discounted the WindMill drivers ? They work with Excel.
>
> >http://www.windmill.co.uk/rs232.html
>
> > 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.
>
> 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.

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

>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.

Joerg,

I am ashamed to admit that I don't know if the latest versions of MS Excel
use VB.net. VB.net (at least the free version VB2005 Express) does not
support use mscomm, but has its own serial port control which does not
appear to need additional registration. The control itself is lacking in a
few features, but if Excel now uses VB.net this could be your answer. For
what it is worth I wrote an article on VB2005 Express and the Serial Port
in the December 2006 issue of Circuit Cellar (issue 197).

Actually, I am not sure what you are trying to do. You could turn your
approach around and create your application in VB.net and then control
Excel from VB to achieve your ends. The above article was actually part of
a series in which I created a Modbus interface using the above approach.
The series was completed in issues 200 and 201.

-Aubrey

antedeluvian51 wrote:

>>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.
> 
> 
> Joerg,
> 
> I am ashamed to admit that I don't know if the latest versions of MS Excel
> use VB.net. VB.net (at least the free version VB2005 Express) does not
> support use mscomm, but has its own serial port control which does not
> appear to need additional registration. The control itself is lacking in a
> few features, but if Excel now uses VB.net this could be your answer. For
> what it is worth I wrote an article on VB2005 Express and the Serial Port
> in the December 2006 issue of Circuit Cellar (issue 197).
> 
> Actually, I am not sure what you are trying to do. You could turn your
> approach around and create your application in VB.net and then control
> Excel from VB to achieve your ends. The above article was actually part of
> a series in which I created a Modbus interface using the above approach.
> The series was completed in issues 200 and 201.
> 

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. <shaking head>

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

Rocky wrote:

> On Sep 25, 10:45 pm, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
> 
>>Marc_F_Hult wrote:
>>
>>>On Wed, 19 Sep 2007 15:05:22 -0700, Joerg
>>><notthisjoerg...@removethispacbell.net> wrote in message
>>><A%gIi.4992$Sd4.1...@nlpi061.nbdc.sbc.com>:
>>
>>>>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?
>>
>>>Hi Joerg,
>>
>>>Have you discounted the WindMill drivers ? They work with Excel.
>>
>>>http://www.windmill.co.uk/rs232.html
>>
>>>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.
>>
>>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.
> 
> 
> 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
> 

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

Joerg wrote:
> 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. <shaking head>

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.

In article <LovKi.9066$JD.147@newssvr21.news.prodigy.net>, Joerg says...
> 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. <shaking head>

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

Clifford Heath wrote:

> Joerg wrote:
> 
>> 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. <shaking head>
> 
> 
> 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.
> 

40MB to get to the ports, wow ...


> 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.
> 

I've heard the same whine from hardcore SW guys, except that some of 
them used words I could not repeat in public.


> You should be congratulating MS for finally doing something positive about
> solving DLL hell, not castigating them for your mistake.
> 

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

Robert Adsett wrote:

> In article <LovKi.9066$JD.147@newssvr21.news.prodigy.net>, Joerg says...
> 
>>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. <shaking head>
> 
> 
> 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.
> 

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.


> Just in case you were wondering why disk and memory requirements keep 
> climbing w/o bound.
> 

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

Joerg wrote:
> 40MB to get to the ports, wow ...

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.

> Your are probably right. However, that's a "version control" scheme that 
> is totally foreign to me.

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.