AB Series- A Basic Module

L

Thread Starter

L.C Rosario

Problem of downloading programs to AB series A Basic Module

Message text:
Does anyone know what software to use to download programs to an Allen Bradley 1771 series A basic module? I managed to upload a program and do online editing using the PBase software which works like a charm for a series B module. The problem is every time I try to download to the series A , the listed program looks like bits and pieces are missing and the program never downloads to the last line. I've ruled out the problem of it being the module itself as I have tried with another series A as well.... I've also tried using Hyperterminal and DaCom but am still losing sleep...

Thanks in advance
 
Leon,

PBASE software was meant for the 1746-BAS and the 1771-DB Series B modules. While you can use it to monitor a program in a 1771-DB Series A, it will not work for uploading or downloading.

DaCOM, ProComm, or regular old Windows Hyperterminal should work as a terminal program for uploading and downloading to the 1771-DB/A. Set Hyperterminal to use Control-keys as terminal keys instead of Windows keys (the module needs to see Ctrl-C, for example) and it should work fine. Be absolutely certain your serial cable is good; try using the same cable (it's just a three-wire null-modem) to upload and download to a PLC-5 Ch.0 port.

Good luck,

Ken Roach
A-B Seattle
[email protected]
 
It's in you ASCII settings in Hyperterm..Try adding some time to LINE DELAY and CHARECTOR DELAY. It takes time for the BASIC module to
digest the information. I think I used 50ms or so.. Good Luck..
 
J

Jeremy Pollard

I would try to reduce the baud rate. I also have a cutom download program whcih waits for the ACK back from the module. Dont believe that the series A module buffered as much or as well thus
Series B:)

Let me know if I can help - I would try 300 baud - seriously.

Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
M

Michael Griffin

If this is the hardware I think it is, then it is hosting version of Intel Basic. It expects you to be typing your program into it using a terminal. When you press the "enter" key, it takes the line of code and "tokenises" it. That is, it checks it for syntax and stores it in a more compact form (which also allows it to execute faster). When it is ready for the next line, it displays the ">" prompt.
When you "download" a program, you are really just being a very fast typist. The interpreter may not have enough time to digest one line before you send the next one. This can cause it to over-run its recieve buffer, after which it throws out whatever comes next. This causes parts of various lines to disappear. When it gets some nice easy stuff to tokenise, it can catch up to you, which is why you don't lose everything.
The AB module isn't the only one with this problem. It is inherent in the fact the old Intel interpreter doesn't really have a "download" mode.

There are two solutions. One is to set your "send" baud rate down to a lower value when you download. If you send at a low enough rate, the interpreter can usually keep up.

The other way is to use a terminal emulator which has a "line wait" setting. This is a setting or command which causes the terminal emulator to wait until is sees a specific character echoed back before it sends the next line. If you set it to wait for a ">" character, it will wait until it sees the next prompt before sending another line of code. This "paces" it to the speed of the interpreter, avoiding the possibility of over running the buffer.
The terminal emulator of course cannot see the difference between a "greater than" symbol being echoed back and a prompt (also ">"), but this will not normally occur frequently enough to cause a problem. (At least it has never been a problem for me.) The receive buffer has enough capacity to accept the occasional line (actually quite a few lines) like this and the transmission is actually still held up until it hits the ">" character so there is still some pacing occuring.

In either event, you should always upload the program you have just downloaded, and compare the two using a compare utility. This makes sure you haven't lost anything. It also finds mistakes like duplicate line numbers (the first instance of the line dissappears). The interpreter will re-format the text as part of the tokenise-detokenise process, so you may wish to ensure you write the program in the same format the basic module will spit it back to you in unless you have a fairly clever compare utility.

If your next question is what terminal emulator to use to get the "line wait" feature, I can't be much help there. I use an ancient (DOS) version of Crosstalk, because I have used it for some time (with DOS software), and I haven't had a strong incentive to change. If anyone has a suggestion of a simple Windows equivalent, then I too would be interested. I have found most Windows terminal emulators to be either too simplistic, or too horribly complex.



--
************************
Michael Griffin
London, Ont. Canada
************************
 
B
Windows Hyperterminal has settings for line delays and/or character delays. A very handy feature for sending data to older systems like this.

Bill Sturm
 
M

Michael Griffin

As far as I know, these are only *delays*, not the ability to respond to an
echoed character. You need to set them fairly generously to be sure they will be OK, which means you are going a lot slower than you need to.
The feature which I have been using in Crosstalk is the ability to specify waiting until a particular character (the '>' prompt character) was echoed back. This was very nice, because it means the terminal emulator can adapt to the speed the Basic Module is able to accept data at.
I haven't been looking too hard recently, but I found Hyperterminal too simplistic, and the more advanced packages too complex. I wouldn't mind finding something somewhere in the middle. This field isn't a growth area for software sales though, so there really isn't a lot of new development going on.

--
************************
Michael Griffin
London, Ont. Canada
************************
 
Y

Yosef Feigenbaum

When I wrote DaCOM I included a feature to allow
you to use XON-XOFF handshaking. Lowering the baud will help but if buffers are full on the DB end, you will loose data.

Yosef Feigenbaum
Ludan Engineering
[email protected]
 
J

Jeremy Pollard

I have a piece of software that was written specfically for Series A Basic modules Please contact me directly for a copy should it be of service:) Waits for the '>' before sending the next line so takes the tokenizer lag into account.

DOS based and takes control of the serial port - FYI

Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
C

Curt Wuollet

You might also look at DOS Kermit. Lots of things that can be tweaked. The Windows version is not as configurable from what I hear, I haven't had any desire for Windows terminals on my *nix systems so I can't say for sure. The source is available so if all else fails you can make it do what you want. Of course, an old PC or notebook with Linux and C Kermit make a fine terminal with extensive control and the termcap or terminfo entry can also be tweaked to match almost anything. This setup is the ultimate terminal. I've needed the versatility several times to talk to ancient and/or obscure hardware whose terminal attributes, codes, and characteristics were lost in the shifting sands of time. After all, who does terminals better than *nix?.

Regards

cww

 
M

Michael Griffin

Thank you, but I already have a DOS terminal emulator which can do this, as well as other tasks. I was looking for a Windows equivalent. Unfortunately, all the Windows terminanal emulators seem to be either too simplistic (e.g.,
Hyperterminal) or too complex.
The need is actually less for me (I'm satisfied with what I have now) than for our maintenance personnel. We've tried several commercial Windows terminal emulators in the past, but they were all so complex that we always ended up going back to an old DOS program.


************************
Michael Griffin
London, Ont. Canada
************************
 
J

Jeremy Pollard

Stuff was written back in 1986. Yikes - we still have to rely on crap written 16 years ago to support hardware that was badly designed at the get-go? What were we thinking?

Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org the Training Factory, Inc. Programmable Controller Support Systems The Software User Newsletter ONLINE The Crazy Canuckian! 8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
Top