Bobs Tools

[lwarren]

Anybody have the Bobs tools software? Mine got corrupted somehow. I am mainly interested in the spannit.

Thanks

[lwarren]

Never mind, I wrote my own Span-it program.

[Paul Pippin]

excuse my ignorance but what is Bobs tools software? never heard of it.

[codewriter]

excuse my ignorance but what is Bobs tools software? never heard of it.

Search button:
http://www.hvac-talk.com/vbb/showthread.php?t=116911&highlight=bobs+tools

[Paul Pippin]

thanks

[lwarren]

excuse my ignorance but what is Bobs tools software? never heard of it.


It was a set of programs written by an engineer that worked for JCI. Most of it pertained to JCI, but as I remember there was a program called spannit that would allow you to span an output based on an IO input. IE, if you had a sensor like a photocell, and it inputed a 0-10v and the output range was 0-500 FTC, you could enter the values and see precisely what the output should be at 3.35896 volts or whatever.

I am kind of lazy and don't like doing math, so I just created one. Maybe I'll call mine lwarrens tools. LOL.

[osiyo]

It was a set of programs written by an engineer that worked for JCI. Most of it pertained to JCI, but as I remember there was a program called spannit that would allow you to span an output based on an IO input. IE, if you had a sensor like a photocell, and it inputed a 0-10v and the output range was 0-500 FTC, you could enter the values and see precisely what the output should be at 3.35896 volts or whatever.

I am kind of lazy and don't like doing math, so I just created one. Maybe I'll call mine lwarrens tools. LOL.

Hey, that'd be better than all the bickering about which is better, Lon or BacNet.

I read those posts, but only with a view to try to learn something useful to me that I can use in my day to day work. As the folks for whom I work deal with Lon, BacNet, and proprietary protocol devices. And that's HIGHLY unlikely to change in the next few years. There is work to be done and customer demand in all three areas, and we intend to get our share of said work.

Anyways, scaling is always a handy thing to know. And it's pretty simple, straight-forward math. At least for linear devices.

For those who might be interested.

Let's take an example of a pressure transducer which has an input capability of 0 to 30 psi, and an output that'll be 4 to 20 ma (miiliamps for any beginners). Pretty common devices.

Let's say you hook up a meter that can read milliamps directly to the output and you read 12 milliamps. What's the current pressure in PSI being sensed by the transducer?

To figure this out you need to go thru some simple steps.

1. Determine the full scale of the Input of the device. Which would be the maximum psi reading possible (30 psi) minus the minimum (zero psi), or 30.

2. Determine the full scale of the Output of the device. Which would be max output minus min output, or 16 in this case.

3. Divide full input scale by full output scale (in this case, 30/16) and you'll get 1.875 ... which is called the SLOPE.

4. Now determine the offset. The offset is a function of the difference numerically between the starting point of the input as versus the starting point of the output. In the above example, zero as versus 4.

To calculate offset it's the minimum of the input minus (Slope times output minimum), or 0-(1.875*4) in this case. You get an answer of -7.5

5. Now you're all set to go. In this example let's assume a meter reading of 12 milliamps. To figure out what the pressure is in psi:

Current PSI = (12 times Slope) plus Offset or
Current PSI = (12*1.875)+(-7.5) = 15 psi

Same method can be applied to most sensors of all sorts of ranges and output types; 0-20 or 4-20 ma, 0-5 volt, 1-5 volt, 0-10 volt, 2-10 volts, etc.

I carry a calculator always, but am lazy most times. For things like this I'll either set up a fast and dirty spreadsheet in Excel or do a fast, simple console mode program using FreeBasic (makes tiny executables and runs on most versions of Windows or Linux) and make a link to it so I just have to click and punch in the number quickly and get an answer.

One of these days ... I gotta look into a new Palm or something. Got a really old one but it quit working some time ago. But as it stands, gotta break out the laptop (a pain if I haven't already got it set up), or the calculator and do it the hard way.

Used to have a bunch of handy calculation apps set up on the old Palm, they're all gone now. And I haven't made up my mind about a replacement. Been waiting for prices and abilities to match up with what I want. I don't want a "do everything plus wipe your A** for you !" unit. Too much of a PIA plus break or lose ONE thing and you've lost a bunch all at one time. Phone, camera, PDA, etc. I'd like a plain old handheld, fairly rugged, general purpose computer for keeping notes, running small custom apps I program for it, etc. Kinda like my old Palm, but a LOT more memory. Gotta look into it, but I keep procrastinating.

[codewriter]

"There is work to be done and customer demand in all three areas, and we intend to get our share of said work."

classic...

[osiyo]

"There is work to be done and customer demand in all three areas, and we intend to get our share of said work."

classic...

Hmmmm. I like to think so.

Of course, I don't know if you are thinking of "classic" with the following definition:
Of a well-known type; typical

Or with the definition I tend to prefer and use:
Having lasting significance or worth; enduring

A major goal of the work we do is to have a lasting significance and worth to our customers.

There are a lot of players in the DDC biz. Ranging from small one and two man shops up to large multi-national corporations. With skills, abilities, capabilities, and reliability running the gamut from half-a**ed to excellent.

And all of them claiming to be better than the other, one way or another. Some claiming superiority in EVERY measureable way.

<Shrug> Who to trust? Who to believe?

That line above is the most frequent thought expressed by many of the customers I deal with. They've heard, or read about, all the claims and counter-claims, hype, and touts. And in many or most cases have had more than their fill of talking to salesmen from this or that company who are like hyped up used car salesmen on steroids who have a deal so good it just can't be refused, and whose product or services are better than any one else's and they're ready to prove it. Got a briefcase full of documents, paper or digital, which is absolute proof their product/services are superior and that their competitors' stuff suck. Problem being, next salesman customer talks to has the same, proving the first guy was lying. Supposedly.

Our goal is to sell a final product/system which meets or exceeds customer needs and expectations within a price both we and the customer agree upon. WITHOUT those nasty little cost increasing surprises being sprung upon the customer during the project. And to install a system, commission it, test it, calibrate it, and provide final COMPLETE and ACCURATE O&Ms of high quality and workmanship which works as advertised, and is reliable and enduring. Works the day we're paid, and is still working just fine 15 years from now.

We're not always able to do the above to the satisfaction of a customer. But we are able to do it 90-95% of the time.

Often enough so quite a large bit of our work is repeat business with the same customers year after year. And we have some (most of em, actually) quite sizeable customers. Successful businesses and organizations, top notch, who are not fools. Most having very competent in-house people and/or with long-standing relationships and contracts with consulting engineers/architects they trust and have had much experience with. So they don't just rely upon our words or claims. Mostly they have past experience with us AND the advice of their own, trusted people.

We deal in Lon (TAC) because that is a solution some of our customers want and sometimes demand. TAC because we specifically like their stuff.

We deal in BacNet because in some cases that is the solution the customer wants, and/or which best fits as a solution to their particular problem. In our humble opinion.

And we deal in two propriety systems. Some work, tho not a large amount, in CSI (now owned by TAC, but TAC still makes several of the old CSI controllers). Because we have previously existing, long time CSI customers whose systems still work just fine for them and they see no durned good reason, at this time, to convert to something else.

The other propriety system is AAM. A large customer base for us. We, as a company, have installed many thousands of AAM controllers. And in any particular year, including the current one, we'll install another several hundred. The customers we have who've used AAM ... LIKE em. Like AAM a lot. And like the way we install them and set things up. And like the price, the reliability, and the support. And have no durned intention of changing at this time or in the near future. They also understand the system, many of them. Several having their own in-house people perform maintenance and repair, reconfiguration as it might be needed, minor programming changes, and so forth. So they're still asking us to install AAM on new construction as well as remodels routinely and regularly.

They KNOW the system, have had many years past experience with it in some large scale installations. They know, implicitly and explicitly, it's pros and cons. And they trust it. And they trust our installation and programming and support.

We're not about to argue with em that they should dump it and use something else. It's what they want, what they trust, and it does everything they need and expect.

FWIW, I happen to like Lon ... at least TAC. But, truthfully, I have next to no knowledge of Lon except for TAC's implementation of it.

But I'm not in the business of pushing personal agendas and preferences. I go with what fits the given job, any previously installed DDC systems, and customer preferences/needs/wants/pocketbook. And simply concentrate on producing the best install and final product/system that I can.

I gage success by whether or not customer is smiling and happy with the finished system when I'm done with a job and whether or not said customer calls us again for the next job. To me, nothing else really counts for much. Customer satisfaction is the name of the game. Not some Lon versus BacNet versus propriety protocol system debate.

I am certainly interested in knowing the pros and cons of this system (or protocol) versus that, the quirks and workarounds, the fixes and the proposed fixes, and so forth. And for that reason read most posts that have any relevance at all to things I work with, or might work with. Even the debates I find tiresome where it seems that the debaters are doing little more than finger pointing and saying "Your favorite system sucks!", "Oh yeah? Well, yours sucks worse !!!!", ad infinitum ... ad nauseum. With both sides offering "proof" which is often laced as much with opinion as it is with independently verifiable FACT.

I've come across, personally, people who worked with and used Lon based systems who love em ... AND those who despise em. Same with BacNet systems. Same with this or that proprietary protocol system. Who is right ... and who is wrong?

<Shrug> I don't think there is any perfect system, nor any BEST system which BEST fits any and all circumstances and customers. And tend to think that the individual installer/technician/programmer/engineer, and his or their knowledge, skill, and quality of work often makes more difference than anything else.

But that's only my opinion, which doesn't count for much.

FWIW, most of our AAM work is done for previously existing customers. Folks who LIKE the system, often have used it since back in the early to mid-90's, and who intend to stick with it for several years yet.

Most of our BacNet work is with jobs that require interfacing one system with another. But don't get many requests for new, completely native BacNet systems. We could do them if asked, have done so. But most of our BacNet work involves interfacing disparate systems.

Most of our new work with new customers is Lon, specifically TAC systems. As we are a TAC dealer, and prefer their systems for a number of practical and pragmatic reasons. I'm not even saying they're the best of Lon compatible manufacturers. I wouldn't even know, for sure. I happen to like their stuff, personally. And their support staff. But I don't really have anything to compare them against except Honeywell's Lon stuff from a few years ago. Don't know about their new stuff at all. As we no longer do Honeywell, nor have a desire to.

Except in the case of the Tridium devices. I gather Honeywell owns them now? I don't really know but I think I read that somewhere. In any event, we have started to deal in relabeled Tridium devices. AAM has one they call "Integra". I know little about the inner workings, have had the introductory lectures and such, but that's about it. Have seen some we have installed here and there. In one case even figured out, on the fly, how to modify as screen that was faulty. Seems to work well. I'm kinda excited about it. I do like new toys to play with. And it seems to offer a solution customers want in some cases.

However, we're still in the learning phases as concerns the Tridium devices. Just setting one up and getting it to work seems to be simple enough. An opinion told me by one of our people who's actually had training on the devices. I personally don't know as I haven't done anything more than modify a screen on one. But I watched him set up an installation. And he was flying and whizzing thru it faster than I could follow. Seemed to be having no troubles at all. Of course, he's had the training ... AND he's without a doubt much brighter than I am. (Most people are)

But we're still discovering the reality of the systems. It's practical pros and cons in real world installations. And still trying to figure out when and where it offers the best solution for a given set of problems and customer wants and needs.

Classic - Having lasting significance or worth; enduring

Yeah, I like that. Thanks.

[lwarren]

[QUOTE=osiyo;1328867]
1. Determine the full scale of the Input of the device. Which would be the maximum psi reading possible (30 psi) minus the minimum (zero psi), or 30.

2. Determine the full scale of the Output of the device. Which would be max output minus min output, or 16 in this case.

3. Divide full input scale by full output scale (in this case, 30/16) and you'll get 1.875 ... which is called the SLOPE.

4. Now determine the offset. The offset is a function of the difference numerically between the starting point of the input as versus the starting point of the output. In the above example, zero as versus 4.

To calculate offset it's the minimum of the input minus (Slope times output minimum), or 0-(1.875*4) in this case. You get an answer of -7.5

5. Now you're all set to go. In this example let's assume a meter reading of 12 milliamps. To figure out what the pressure is in psi:

Current PSI = (12 times Slope) plus Offset or
Current PSI = (12*1.875)+(-7.5) = 15 psi

Same method can be applied to most sensors of all sorts of ranges and output types; 0-20 or 4-20 ma, 0-5 volt, 1-5 volt, 0-10 volt, 2-10 volts, etc.

I carry a calculator always, but am lazy most times. For things like this I'll either set up a fast and dirty spreadsheet in Excel or do a fast, simple console mode program using FreeBasic (makes tiny executables and runs on most versions of Windows or Linux) and make a link to it so I just have to click and punch in the number quickly and get an answer.

Osiyo -
Is Free Basic a free program?

I wrote my program using JustBasic, I originally used your formula above to do the calculation, however in my code it only worked with the output starting with zero. So I used a different formula which I believe is easier for someone who would just be using a calculator. Using your example above if you take the 4-20ma output and add 20+4=24, then add your input range 0+30= 30. Now divide the input 30 / 24 and you get 1.25. Multiply that by 12 and you get 15.

Not that this way is better it just eliminates figuring the offset.

[osiyo]

Osiyo -
Is Free Basic a free program?

I wrote my program using JustBasic, I originally used your formula above to do the calculation, however in my code it only worked with the output starting with zero. So I used a different formula which I believe is easier for someone who would just be using a calculator. Using your example above if you take the 4-20ma output and add 20+4=24, then add your input range 0+30= 30. Now divide the input 30 / 24 and you get 1.25. Multiply that by 12 and you get 15.

Not that this way is better it just eliminates figuring the offset.

There are many ways one could calculate the numbers. I only gave one, the one I'm used to using.

Yes, Freebasic is free and open source.

Main page with intro and links to download. Versions are available for DOS, Linux, and Windows.
http://www.freebasic.net/

The FreeBasic forum
http://www.freebasic.net/forum/

The forum has about 1700 registered users, and several times that of unregistered, regular visitors. Registration is not mandatory unless you want to make a post yourself.

Freebasic started as a 32 bit version of QBasic, meaning among other things that it can use as much memory as yah got, without having to resort to segments, memory paging tricks,etc. It compiles it's code to straight machine language, small and fast.

The basic language is lean and mean. In the beginning, virtually a clone of QBasic 4.5. Since a number of other commands, statements and structures have been added to "update" the language. To give it modern capabilities, use of memory pointers, elecments of structured and OOP language, etc.

But the barebones of it are still pretty stark. Addition commands and abilities are added by INCLUDING libraries of additional commands and abilities. There are MANY such, most free. And many are included in the download. You just need to remember to use the INCLUDE statement in your program to be able to use whichever library you choose to use.

Users are always adding additional libraries and wrappers to expand it's abilities. Coverting C and C++ libraries to a form usable by FreeBasic is pretty simple. And thousands of those are out there, freely available.

It has built-in graphic commands, similar (almost identical) to those of QBasic, with some extras added. And yes they work under Windows. No GUI native to the language. However a user has a choice of several already made, available and free GUI command add-on libraries you can use. Pick one you like. Personally I prefer FB-GUI, as made by a fellow calling himself Eodor. Since it emulates the same GUI commands, and structure that RapidQ uses.

FWIW, RapidQ is also free. And quite good. Devlopment has ceased, but it has a fairly large user base which is still active.

FeeBasic is still in the development phase. Currently in revision .17. But VERY useable, as is. With commands and statements that not only dupe QBAsic's, but also with advanced commands beyond those QBasic had. Compile with the -lang deprecated command if yah want it to "revert" to being virtually a clone of QBasic. Command for command, statement for statement. Or you can used it as normal with it's added abilities that're bult in. Or, INCLUDE the VB compatibility library, or INCLUDE the CRT (C language runtime), include a Java compatibility library, etc.

I still use RapidQ more often than FreeBasic. It's just so easy to use, and I'm so used to it, that I just naturally pull it up if I want to make an app with a GUI interface. A very good implementation of Basic, with easy to use and remember GUI commands and statements. But it compiles to p-code (pseudo-code) that'll include parts of the RapidQ runtime engine. Only one exec file is produced, and no added DLLs or anything is required to be distributed with your program, but minimum size is about 300k bytes (console mode app or GUI). And while fast enough for most uses, p-code will always be slower than native machine code.

OTOH, I regularly knock out little utility programs in FreeBasic, console mode, that come in at around 5k and they're FAST. About the only way to get faster is to use OPTIMIZED C or C++, written by a good programmer.

Speed is relative. For most uses one might program, RapidQ is more than fast enough. Whatever you want to happen, happens before your finger has lifted from the execute key.

But, if one is playing around with making one's own video editing programs, real time moving 3D graphics, multitasking web servers ... and yes, some of the guys using FreeBasic are doing such things ... there is a need for speed, all you can get. One of the reasons quite a few of the regulars on the FreeBasic forum are gamers. Who make their own high resolution, 3D graphical games. And for such, you need all the speed you can get.

FWIW, HotBasic is also pretty durned good. Near clone of RapidQ, thus easy to learn and use GUI commands. AND ... it compiles to straight machine language code and is thus very fast, and the resultant programs, even GUI interfaced programs, are pretty durned small. But it's not free. Costs $69.

[lwarren]

Thanks Osiyo, I'll check it out. JustBasic is also free and pretty user friendly with a good forum as well.

Im a pretty novice programmer, but basic sure seems alot easier to grasp to me than Java. However, since I am using Tridium now it would be nice to learn Java as well.

[osiyo]

Thanks Osiyo, I'll check it out. JustBasic is also free and pretty user friendly with a good forum as well.

Im a pretty novice programmer, but basic sure seems alot easier to grasp to me than Java. However, since I am using Tridium now it would be nice to learn Java as well.

BASIC is a good, basic, general purpose programming language. Simple, purposefully so. It is one of a number of programming languages I work with, and I keep it handy specifically for knocking out quick and simple utilities.

I'm not familiar with JustBasic, so can't comment upon it.

Java is okay. Kinda slow and clunky. But it's popular since it's mostly (not completely) platform independent. That is, a program written in Java -should- run on any computer which has a Java Runtime Engine (JRE) installed. And Java programs, properly written, can run across network connections. The very reason most online gaming sites have their games written in Java.

You can download not only Sun's Java JRE for free from their site, but also the full developer's package. And they offer links to IDE's, commercial and free ones. A Google search will return an almost endless array of sites offering free tutorials, sample code, function libraries, etc.

So, to learn, the only thing it should cost yah is some wear and tear on the old brain cells. And time.

Myself, I tend to do better in learning something new if I have an old fashion book in front of me. Have a habit of making notes right in them, marking key pages with those little adhesive tabs, etc. And a book is something I can read a bit, then put down and think about. Jump back and forth easily between new reading and something I read before to refresh memory and past thought processes. A book is convenient to grab and browse at the spur of the moment when one has a few moments between doing other things. Etc. So some time ago I bought Java Programming Fundamentals by Kimberly Seefeld. And liked it. Kimberly introduces the concepts gently, simply, and in a logical fashion. That's to be expected actually. Since folks who make a living by writing text books tend to become very good, over time and if they become successful at text book writing, laying things out in a fashion that a newbie can understand. But to become a good text book writer takes years and years of not only studying the subject matter, but also studying and learning how to write an understandable text book. So, those kinda folks don't tend to give their books away free.

But as a suggestion, yah might go to a good bookstore and lightly browse thru what they have by way of Java texts (they'll probably have several by different authors) and look for one who writes in a way that's understandable by you and whose writing style appeals to you personally. A good, understandable text to one man, is often incomprehensible jibberish to the next. Or so boring to the second person he can't "get into it". So, if interested, don't buy the first you see. Browse for one with a style that appeals to you personally.

Just my thoughts.

[codewriter]

www.w3schools.com

You can start learning java there, as well as many others.