Uploading ASCII file issue

[kevin906]

I am trying to upload an ASCII file to a PBX command line.

File is simple commands:.
DIS-SCSU:2345,ALL;

Trigger is the < symbol for sending the next line.
I know I can also write a script to do the transmit ...
trying to save some time.

For some reason the data string (DIS-SCSU..) is not being recognized by the PBX, I only get a blank line where the CR/LF was sent with no data, the < symbol triggers the next line to be sent and it repeats. If I abort the transfer it will generate the last line sent as the transfer is aborting to the PBX. I know I have done this in the past, wondering if I missing something obvious. I realize it could also be the PBX that is the culprit.
Any ideas?

 

[knob]

You are doing this using an ASCII file transfer in Procomm, correct? Is it only a one line file or several lines? If one line, you might try copying the text and then pasting it into Procomm to determine if the problem is the data itself as opposed to the process.

http://www.aspectscripting.com

 

[kevin906]

Using Procomm Plus and Ascii upload for the file. File is plain text, cutting and pasting to command line is no problem, syntax is good. The issue is the data does not appear to get sent to the PBX, each line that is "sent" results in a "No Command Entered" from the PBX. It's as if
I am just sending CR/LFs to the PBX without any data.

 

[knob]

Are you doing ASCII or raw ASCII and what are your current settings in the Procomm Setup dialog (can right click the protocol name in the quick select line at the bottom of the window)? Has this ever worked in the past?

http://www.aspectscripting.com

 

[kevin906]

Has worked in the past. Using ASCII protocol, Don't translate CR or LF. I tried changing these to different combinations with no luck. 10 millis. delay between characters. 10/10 second delay between lines. Using < as the pacing character. < is command line prompt from PBX to signal command completion.

 

[knob]

You might double check that your values were retained as there is a known bug with some of the ASCII transfer values not being saved/restored correctly (see below text from my website). I'm not sure you need the pacing character set for this scenario, but I am having problems getting Procomm installed on this laptop for some reason and can't investigate quite yet.

If you try to set the value of the ASCII transfer protocol's line pace character by entering the ASCII value of the character, you may notice that this value is set to 255 when you exit Procomm Plus, restart the application, and double check the setting. There are two possible workarounds for this problem. If the character you wish to use is printable, simply enter the character instead of its ASCII value. If you wish to set a non-printable character as the line pace character, you will need to use an ASPECT script to set it. To do so, create a script with the line "set ascii pacechar value" where value is the ASCII equivalent of the pace character you wish to set. Once your script has run, the line pace character value will be set. However, if you ever open Procomm's Setup dialog and click the OK button, the setting will revert to 255. To minimize the chances of this happening, I recommend adding the set command to the end of STARTUP.WAS (just above the endproc command) so that the pace character is set each time Procomm Plus is launched. The same problem also exists for the Raw ASCII transfer protocol - the script command to use in this case is "set rawascii pacechar value."

http://www.aspectscripting.com

 

[kevin906]

You are on to something here for sure. As soon as I unchecked using pace characters it starts to send the data. Except it's overrunning the buffer and the data looks interlaced with next and previous command results. But this for sure has an effect on the transmitting of the characters. I will keep on experimenting. Thanks for steering me in that direction.