adccommunitymod (AutomationDirect) asked a question.
Co-Processor Data Upload/Download
Created Date: June 22,2006
Created By: AZRoger
**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****
I have a BASIC-M coprocessor for a 205 250-1 CPU. I can get programs to upload (to be saved on my development PC disk) as long as the program is stopped. However, I can't find a way to upload the data tables. I can use I/O (print and input) to the non-command port to get the data to another program which can do the saving thus getting the result I want. Is there a more straight forward way to do this that I just missed in the documentation? Pointers to the place to read would be great.
Created Date: June 22,2006
Created by: FACTSTech
The F2-CP128 BASIC CoProcessor must be in command mode (program stopped) before you can send any commands to the module or upload/download a program, this is normal.
By "data tables " I assume you mean string variables, non-dimensioned variables, and dimensioned variables within your BASIC program. There is not a defined function to upload/download these variables all at once. If you need to dump these values out of the serial port, a series of PRINT statements in your program is the easiest way to do this.
Created Date: June 22,2006
Created by: AZRoger
Thanks. Just trying to save a few lines of code.
I have a separate request into tech support (which you may get) about port cabling. The module came with one cable and adapter which I'm using on Port 2. I need its twin to operate on Port 1, which is connected to another PC. I can't find a way to order the FACTs part and none of the AD cables is exactly right...
Created Date: June 22,2006
Created by: FACTSTech
Part number FA-CABKIT has the 6P6C cable and the DB9 Female connector.
http://web1.automationdirect.com/adc/Shopping/Catalog/Communication_Products/Serial/FA-CABKIT
Created Date: June 22,2006
Created by: AZRoger
Thanks. I ordered the FA-CABKIT and it's on the way.
Created Date: June 29,2006
Created by: RHanrahan
AZ,
I just wrote a seperate program to do the data table dumps when needed. Since this file can get a little large, I found having it in a seperate table helped with the program processing speed. I then just called it from the main program whenever a bit was set in the PLC.
Robert Hanrahan
Created Date: June 30,2006
Created by: AZRoger
OK, let my lay out assumptions that I think are true but may not be...
1) Variables DIMd in command mode will be shared by all programs. These are the "tables " to be uploaded.
2) Only one program runs at a time.
3) GOPRM is the method for CALLing programs
4) Any program doing writes via PRINT will be slowed to the bit rate of the communications channel.
4) ONPORT only handles incoming characters to be read by input or inkey$
5) To avoid blocking the main program for long periods of time, the dumper program has to write only a little bit at a time and then go back to the main program -- without clearing the "please dump now " bit Robert mentioned.
6) To avoid having the second program wait on PRINT operations, it needs to know when it can issue another PRINT without being held up.
7) The dumper communications channel is through a second connection to the co-processor. The PLC CPU doesn't even know it's there.
The key questions are:
How can I tell when it's OK to PRINT with no communications delay from the interpreter?
How do I know how many characters of space are available in the output buffer?
How do I know when the output channel is idle?
One scenario has the second program write a buffer load of characters to the other PC and return to the main program. Once the other PC had received that buffer load of data, it could send a "go ahead " character to the co-processor. The main program could then detect that input via ONPORT. It could then call the the dumping program to send the next batch of data.
Another scenario would use ONTIME and pace the data out of the co-processor at a rate less than the communication port is capable.
I'm not worried about single scan response times from the co-processor. I wouldn't get it anyway. However, I'd like the co-processor main program to respond within 1/4 of a second at the outside. Synchronous PRINTing would take much longer than that.
Created Date: July 03,2006
Created by: FACTSTech
When the interpreter executes a PRINT statement, the PRINT statement transmits all characters specified by the PRINT statement then program execution passes to the next statement.
>How can I tell when it's OK to PRINT with no communications delay from the interpreter?
There will be some interpreter overhead on all BASIC statements. The serial communication time (1/baud*databits*number of characters) will be the majority of execution time of the PRINT statement.
>How do I know how many characters of space are available in the output buffer?
There is not really an output buffer. The PRINT statment transmits characters from string or numeric variables specified in the PRINT statement directly to the specified port.
>How do I know when the output channel is idle?
If there is not a PRINT statement executing then the port is ready for output.
Created Date: July 03,2006
Created by: AZRoger
FACTSTech, Thanks. I'll put PRINT pacing logic in the main loop of the main program. I'll not bother with the GOPRM approach as it would just add overhead for each "block " of PRINTed characters. Thanks again.
Created Date: June 22,2006
Created by: AZRoger
I have a BASIC-M coprocessor for a 205 250-1 CPU. I can get programs to upload (to be saved on my development PC disk) as long as the program is stopped. However, I can't find a way to upload the data tables. I can use I/O (print and input) to the non-command port to get the data to another program which can do the saving thus getting the result I want. Is there a more straight forward way to do this that I just missed in the documentation? Pointers to the place to read would be great.