On Thursday 11 January 2007 11:42, Jacob Yocom-Piatt wrote: > J.C. Roberts wrote: > > You could automate everything as a shell script using only the > > utilities in the base install, in short telnet over serial. > > > > > > sounds interesting, i'll see what i can do with this first. any > further info you could provide here would be nice. >
I always start with running the various SCPI(ish) commands manually in a terminal emulator. If forced (by threat of death) to work in ms-windows, then I use the typical hyperterminal, otherwise I'll go with tip/cu or similar. You may want to note the docs for the CUB5 states it works in half-duplex mode, while tip/cu are normally full duplex (use the -h switch on cu). After figuring out what commands should be run, the proper order and the expected results/failures, life gets easy. hmmm... I did a good job of avoiding your question above. It's a mental block, you know, the kind of subconscious "forgetting" which happens after a really horrific trauma. Anyhow, I'm terrible at shell scripting and always have been. I get fed up with the syntax and cross platform bugs in a matter of minutes, give up, and go grab a "better" language to use (where "better" simply means "the devil you know"). Since I'm probably the worst person you could ask, hopefully one of the many shell scripting gods inhabiting this mailing list will chime in on how do useful work in shell scripts with serial. > > I usually don't get the luxury of UNIX shell scripting, and often > > have a cross platform requirement, so I normally do the coding in > > perl. The following ports will be needed and they have win32 > > counterparts. > > > > /usr/ports/comms/p5-Device-SerialPort > > /usr/ports/net/p5-Net-Telnet > > > > > > if i need more involved data collection, i'll do it in perl or C, > thanks for the pointers here. > > > PLEASE BE WARNED: If you have strict timing requirements, > > particularly machine operator safety requirements (i.e. people > > operating potentially dangerous machines), the *ONLY* correct way > > to do machine automation is to use a (hard/soft) real time > > operating system and write your code in C to enforce your timing. > > > > > > <sarcasm> > and this whole time i thought the correct way to automate machines is > to expose them to a myriad of repeated short video clips on a > television, have them join a fraternity and put a big ol' ladder in > front of them. i can't wait until we can code that in C. > </sarcasm> > :) > i am well aware that running heavy machinery can be extremely > dangerous. this data is only being used for performance analysis and > has no effect on the machinery in question. your concern is > appreciated. > Don't let the "machinery" word, heavy or otherwise, give you a false sense of security. Little stuff like when voltage is applied, can make a big mess in a hurry. Damaging equipment is nearly as bad as damaging people... well, maybe that depends on the person. Let's see, a spectrum analyzer which cost more than a house in California or that lazy coworker which never does anything useful... -I better not complete that thought. Anyhow, since there is no guarantee that your process/thread/interrupt will be serviced by the kernel within "X" amount of time, the non-realtime operating systems should not be used when doing "time critical" automation on dangerous or delicate equipment. The good news is there are only a few classes of problem which are actually *that* "time critical" so loose timing on a non-realtime OS is far more than enough in most cases. Kind Regards, JCR
