Howdy all. The ST datatype and associated data file creates a word length of 80 characters by default.

Does anyone know of a way to reduce this word/character count? Thx in advance

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesign.com Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579

 

Thats true. But you can save string data in integer and bit files if you want to.

You could also create a user defined data file in contrologix that was an array of 8 bit integers and make the array less than 82 bytes long.

I guess alot depends on why you would want to do such a thing in the first place.

 

Barcodes of 20 characters, and a ton of them .. but using ST DT's you lose 35 words of memory per .. Handling in Integer files might be a pain .. BUT ... with 999 per file and
10 files and an index it could be done ..

10K and it would be less than the 256 file size for ST... searching etc would be a pain...

PLC5 and SLC500 is the platform so CL not an option right now

Thx Bob .. you are always one of the most frequent responders...

Cheers from: Jeremy Pollard, CET The Caring Canuckian!

 

This kind of thing is a snap on a PC. I've probably got code for a sorting conveyor that took a barcode and looked up a location. That would be in C for Linux. Handled many barcode readers and sent the results serial to a PLC. Had a crude curses HMI and a B-Tree database. Very small and fast. The whole project went up in two weeks when the software that came with the conveyor system was a disaster (VB?) and we were challenged to fix it in two weeks.

Regards

cww

 

Hi Jeremy,

You can define a new STRING DataType with a maximum length of 20 chars. You will then be able to use the existing ASCII instructions with the new DataType.

A STRING DataType must have a length field (DINT), so each of your barcodes will occupy 24 bytes.

 

A possibility is to use our Omnii-Comm product to process the strings from the bar code reader for you.

It could, for instance, simply extract the pertinent data, convert it to the appropriate data type and then simply write it to a data file in your PLC.

Have a look at our Omnii-Comm here http://www.miille.com/PCds.htm
It is available in several different form factors and is 100% compatible with many different PLCs.

There is no ladder logic required. Data is extracted from the ASCII string and sent directly to the appropriate PLC location.

Jerry Miille

Miille Applied Research Co., Inc.
http://www.miille.com/

 

It's a snap in ControLogix too. less so in a PLC5 or a SLC.

 

Allard - thx for the heads up but I am using a PLC5 so no custom data types.

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

 

Thx Jerry - since it is a PLC5 the resulting datatype has to be string due to length so I'm stuck... unless the outboard card can store and parse 900 20 character barcodes.

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesign.com
Manufacturing Automation www[.]automationmag.com

 

Thx for this Curt - customer needs to have local parsing since the PC is virtual and not in the same building... reliance on outside comms... guess it's not too reliable!!???

Guess we're stuck with the string length!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

 

Barcodes and string handling are very easily handled within PACs, particularly Opto 22 SNAP PACs and their included software suite, PAC Project (http://software.opto22.com). In fact, the free PAC and software training offered at Opto 22 headquarters includes barcodes, string handling, and RFID as part of the curriculum.

I realize this is shameless plug for Opto gear, and perhaps you're already committed to the AB platform for this job. But two things: I don't know how to help you with your older PLC gear; and, I know you have some Opto PAC hardware lying around up there in the Great White North that I personally sent to you. Put it to use, and see for yourself. No further capital investment needed... just an hour or so of light programming. And don't worry about running out of RAM. Your Opto SNAP PAC has 16MB of it, and can easily handle thousands of strings or string arrays.

Good luck!
-Benson

 

Is this a sort or verify application? It makes a big difference as to how to deal with the problem.

For a verify application, you could store the bar code string in one type of memory, and copy it to a different location for comparison. For a sort application, the stored bar codes need to be searchable, which limits the flexibility. I haven't done bar codes on a PLC5 (plenty on other types of PLCs though), so I don't want to recommend a particular method.

However, 900 bar codes is a lot of bar codes even if you have plenty of room in the PLC. How is the customer going to get them into the PLC, change them, or get them back out of the PLC (to check if the list is up to date and correct)? That is probably a more important matter than how to store them in the PLC. The manageability of the data is a problem with that much of it.

If the data is being updated and managed automatically by some sort of network connection, then that may have an over-riding influence on how it is stored. If the plan was to just typing in the data by hand through the programming software though, then it doesn't sound very practical as it will be full of errors.

For this many bar codes, I think that Mr Wuollet's suggestion of using a PC has some merits beyond just being able to store the bar codes. The bar code strings (and any associate data) can be stored in a CSV file that the customer can generate from a spreadsheet. However they are storing their product data (which I assume the bar code is part of), they can usually get it into a spreadsheet to create or validate the CSV file. It also gets you out of the job of proving that all 900 bar codes in the PLC are correct and can all be retrieved from wherever they are stuffed in PLC memory.

It's hard to recommend a software solution without knowing the application. If it's just "1) read a bar code", "2) compare or look-up", "3) send a signal" though, then it's really fairly simple.

Some bar code reader vendors have software packages for different applications. A lot of them though are made out of a keyboard wedge, an MS-Excel spreadsheet, and an MS-Access database. I've never seen one of those contraptions though that could be fixed or maintained by anyone other than the guy who installed it. Something simple which was written for the application in a conventional language would probably be a lot nicer and more maintainable.

Many of the larger bar code reader manufacturers have special computers for fork lift or truck applications. I have seen these also used in fixed applications on production lines running customised application software. They could handshake with the control system via digital or serial I/O (which is where I was involved). I wasn't particularly impressed with either the hardware or software though. A regular panel PC would have worked as well in that application and probably been more reliable.

 

Sorry, I was not clear in my earlier response.

The Omnii-Comm can be configured to extract only the data value(s) you are interested in from each string, convert them to integer or float and then write only the converted information to the PLC. The data does not have to be stored in the converter (but it could be). We have lots of options for parsing an ASCII string and converting values, then sorting them and finally "doing something with them" like writing to files in a PLC or storing them in a "database" for access by something else. Our database is pretty large so depending on how much information in the 20 character bar code message is needed, we may easily have room.

You haven't described how the 900 bar code readers are physically connected. Can you shed some light on this?

Contact me directly (my numbers are on our website) if you have any questions (or to straighten me out if I really don't understand your application).

Jerry Miille

 

A shameless plug indeed.. as well as slag on my inability to 'get to the things' I told you I would get to .. damn!!.. tis true - I do have said hardware your honor.. and no sir I haven’t done anything with the barcode software. (picture of JP kicking the dirt with his snow boot!)

I've been too busy trying to figure out to store, sort, and manage 900 barcodes in a PLC-5.. I'm caught in Rockwell land with no place to put them.... (pass the Kleenex!!)

Man - Ive been watching the Young and the Restless for too long!! lol

Seriously tho .. the PLC5 is legacy - cant change
4 barcode readers read in a single barcode.
Diversion list is sent by a Unix app, managed by a PC with my custom software using Automated Solutions Controls (welcome Mark!!) and target
barcodes are downloaded to the PLC-5. up to 900 or maybe even more (as the project gets finalized) need to be resident int the PLC for sorting since the customer does not want to rely on the network once the jobs have been batched.

My design requires multiplexing at the moment within the PLC memory .. but it getting messy .. and memory intensive.. and yes a true PAC would make life easier ...

End app is warehousing ..

I considered the Basic mod.. then I woke up!!

An offboard card might be the best choice?? Will check out the Miile deal - Thx for that Jerry ..

Thx all for your feedback and input - much appreciated

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesign.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579

 

My previous reply was based on the assumption that you had one or a few bar code readers and needed to compare the input from them to 900 different stored bar codes. Is this the case, or does your customer actually have 900 bar code readers?

 

Hey MG - really only 1 reader.. but 900 cartons per shift where the barcodes are automatically generated, a library created, and when the actual carton is scanned like 3 hours later we know where to put it..

Just a sortable, searchable database of strings .. and using ST datatype needs upwards of 30K of storage .. if I can get the string length in the datatype down to 40 characters, then memory requirements are cut in half which is what is needed..

Question for Jerry Miille - is the module you speak of bi-directional??

Cheers from: Jeremy Pollard, CET The Caring Canuckian!

 

If by bi-directional you mean can it send ASCII strings the answer is yes. There are two methods. You can build up a string in the PLC and trigger it to be sent by setting a "trigger" bit. The second method is to periodically send a fixed string or strings.

Thanks,
Jerry Miille

 

Hi Jeremy, We have a couple of systems running on PLC5's with Devicenet Barcode scanners, and using a look up with 300 product codes which relate to the EAN/GS1 (ITF14) barcode. The barcode comes in and is placed in a N register, then we look at the 5 digits with the barcode that are unique to the product. We then have two database files setup with the first value in one and the next 4 in the other, ie N32 & N33.

In a ITF14 code the first 8 values refer to country and company stuff so this should be the same, unless as we are now finding the company starts to make product for another company so this will be different. Also with the changes from EAN to GS1 the code structures seem to be changing so this may make a difference.

As you can have 1000 words in a integer file this would work for our 900. We still use ST files to display and manipulate data but all the lookups are done in integer files with values stored as hex.

Regards,
Trevor Ousey

 

Storing the job list in the PLC sounds ugly. You not only have to store the data, you have to check the list for errors, store each item, and then retrieve them quickly. You might be doing it as a batch, but what happens if the customer wants to send a revised list? Or add to the list? How are you going to search memory for each record when you need to read them? PLCs do a lot of things well, but one of the things they do poorly is acting as a database.

From your description, I am assuming the PC you added is located at (or close to) the sorting operation. I am also assuming the batch job gets downloaded from the Unix server to the PC and then from the PC to the PLC.

There may be some application details that I don't know about, but I would suggest that you consider the following:

1) The local PC would receive the batch job as at present. The job data is then stored in a database. Each record would have a time stamp (this allows old records to be purged easily).

2) The bar code readers would be connected to the PC rather than the PLC.

3) The PC reads the bar codes. The readers might be run on auto-trigger, or they might be triggered by the PLC (or via a handshake), or some other convenient means.

4) The PC looks up the bar code in the database, and decides what has to be done with the carton.

5) The PC handshakes with the PLC (via digital I/O or network connection) to tell it where to send the carton. This is just a simple destination code (e.g. one byte).

6) The item is marked as "sorted" in the database, possibly with a time stamp added.

If my assumption that the PC was located locally was wrong, then you need to add a local PC.

With this there is no need for the PLC to receive, store, or process the batch job. Sort jobs can be cancelled, changed, or added to at any time. There is no need to pause the sorting system while downloading a new batch job to the PLC (which I assume you would need to do in your original proposal). If the customer needs to push a rush shipment through the system before finshing the current batch, they just need to add the new batch to the database and send the cartons through. There is also no practical limit to the size of the batch. If the customer wants to change their business process to be more of a JIT operation, then they can send records in real time to your system (just as long as the job record gets to the line before the carton does).

The PC software to do this would be a fairly simple application. The PLC program changes would be fewer. It also sounds a lot simpler to do as a retro-fit as well (probably a lot less on-site debugging). It would probably be easiest to have this as a separate application from the one which downloads the jobs from the server, even if it is running on the same PC. It would need a simple user interface to display handshake status, bar code data, etc., for troubleshooting purposes.

This sounds a lot simpler than trying to turn a PLC-5 into a database.

 

Nahh... was thinking more along the lines of the module reading and writing to and from the PLC memory.. with BT or something...????

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com