Awloescher

Micro800 ASCII ABL error code 7 issue

5 posts in this topic

Hi all,

I'm completely new to ASCII and trying to figure out where I'm going wrong here.

Application: I need to send 2d barcode data to a KGK Jet model CCS3000L Inkjet printer. Only protocol possibility is ASCII. PLC I have is a Micro850, and the only port option for ASCII is the serial port. I modified one end of a 2707-NC11 cable to connect PLC TxD to printer RxD, PLC RxD to Printer TxD, and PLC SG to Printer SG. I jumpered CTS and RTS at the printer connector, and the 2707 cable I'm using doesn't have wires on the Micro850 CTS or RTS pins.

Printer company verified that I can just jumper RTS and CTS on their side and not connect their DTR and DSR pins (since I'm not using hardware handshaking). I don't really need any flow control for the application ( I don't think...again, ASCII noob here).

Do the CTS and RTS on the PLC side need to be jumpered? Does the DCD pin need to be jumpered or connected to something if I'm not using handshaking?

I downloaded the Micro800 ASCII read and write functions and function blocks from Rockwell library, and they seem to be working, except that I keep getting ABL error id "7". This error states, "Cannot complete ASCII send or receive because channel configuration has been shut down using the channel configuration dialog box." I have the serial port enabled and configured to ASCII, no handshaking, baud 9600 same as printer, no parity check, 1 stop bit, character length of 8.

Any help in pointing out what I'm doing wrong or things to try would be greatly appreciated!

 

ASCII_TEST.ccwsln

Micro850 serial settings.jpg

Program screenshot.jpg

Write_1 FB.jpg

Share this post


Link to post
Share on other sites

Anyone have any ideas? 

I'm going to look into using pUTTY to attempt to communicate with the printer to see if I can find where the issue is.  

Share this post


Link to post
Share on other sites

I found a KB article (access level: TechConnect) that lists that exact error message in RSLogix 500. The fix is :

Quote

Change the driver from Shut Down to ASCII on the channel configuration dialog and retry operation.

Looks like you've already done that. If you save the file and go offline, does the channel show ASCII? How about if you go back online and look?

Share this post


Link to post
Share on other sites

Thanks for your reply and assistance @Joe E..  I had "channel no" value in the canned "Write" UDFB set to 0 somehow. It's supposed to be "2" for the embedded serial port I guess..  I didn't see anywhere in documentation which channel no it should be.  Anyway, the AWA command works now.  I'm not reading anything though from the printer. A few questions about that now:

I'm not using continuous transmission, and the printer is supposed to send an ACK or NACK once it receives data. I'm seeing zero characters in the buffer after I transmit, and I'm getting ABL error id 11, "The requested length for the string is either invalid, a negative number, greater than 82, or 0. Applies to ARD and ARL function blocks. "

Is it safe to assume, then, that either I'm sending character combinations that the printer doesn't like, it's not properly receiving the data, or it's not sending the ACK/NACK in a proper way? Is the best way to troubleshoot this rigging up a cable from my laptop to the printer and using pUTTY or other hyperterminal to figure out if I'm sending the correct data in the correct format?

Write UDFB.jpg

Read UDFB error id11.jpg

Edited by Awloescher
added screenshots showing working Write UDFB and Read UDFB with error

Share this post


Link to post
Share on other sites

So, I found another KB article (access level: TechConnect)
The max length you can send is 82 characters...but that may not be your issue.
They provide sample code to split the message up into 82 character pieces that are sent individually.

I'm by no means an expert in ASCII comms, so I'll have to punt on this one. I've done some of it in LabWindows and in an S7-300 but both have been a long time ago.

Does the printer respond as expected to what you're sending? By printing or whatever you're having it do? You may not need to manually read the Rx buffer of the Tx instruction completes successfully. The Tx instruction may be verifying the ACK signals itself.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now