1734-232ASC Comms to Printer

I know, I know.. not another 1734-232ASC serial communications to printer topic!! I think I have a slightly different one here and I am hoping to gain some understanding of what is going on here. I have a printer installation here on site that works, and I thought it would be a piece of cake to duplicate the installation on another machine center. One is through DeviceNet Point I/O, the new one I planned on Ethernet Point I/O.

Working installation - (ControlLogix / DeviceNet)

1734-ADN with a 1734-232ASC card connected up to a printer. The printer talks Modbus RTU, but it is a custom format message that I send straight over to the printer out of the RS232 port. The printer does not use basic Modbus function codes. So I develop a message as per the user manual, in hexadecimal, send it to the printer over the serial port, and it prints what I want it to print!! Easy!! I did this job about 6 years ago and it has been working ever since.

Semi-Working installation - (ControlLogix / Ethernet I/O)

1734-AENT with a 1734-232ASC card connected up to a newer version of the same printer. This printer also talks Modbus RTU with the same message structure that I use above. When I send the msg to the printer, it freezes and reboots itself. I can send some messages to the printer that I get a valid response back from, but there are a few particular messages that reboot the printer.

This is what I have done to test out the new installation -

*Double check the format of the message to ensure that I have the correct format - All good according to the manuals and previous installation.
*Connect up my laptop and use RealTerm to diagnose the output of the ASCII card - The output message matches the format I am after.
*Try to send a different command message to the printer via the ASCII card - I can successfully send and receive data from the printer when interrogating the error status of the printer for example.
*Send the message that I want out of my laptop using RealTerm - The printer accepts the message and all is good. (this one really miffs me!!)
*Compare the output of the 1734-232ASC module with the output of my laptop using RealTerm - The serial string matches byte for byte.
*Contacted the supplier of the printer for their assistance - We are bouncing things back and forth, but the tech support is slow as they are on the other side of the world.

I read a lot about how the 1734-232ASC is not ModbusRTU, but I am using it else ware without a problem as just a 'serial string sender'.

I am wondering if maybe the 1734-232ASC card is putting out frame header information that I cannot see through RealTerm (or don't know how to), that is different than what ModbusRTU protocol is after on these printers?? The strings from both the 1734-232ASC module and the ones I am sending over RealTerm match when viewed in the terminal window.

By the way, I have these same type of printers talking on Modbus TCP Ethernet on yet another installation. For that one I am talking 1756-L62 to the printers through a Prosoft MVI56-GEC Generic ASCII Ethernet Interface Module. I was not able to use the Modbus purposed Prosoft MVI56-MNET because these printers use custom function codes that are not supported by the MNET card, and in such the header of the TCP Modbus message was all screwed up and the printer rejected the message. I basically use the GEC card to send out the whole string in the format expected by the printer.

I am probably missing something simple, but in the last few days of trying to test this out my head is getting sore and the frustration levels are starting to peak!! Thanks in advance.

I'm not great with comms software, but it's possible that this is a hardware issue:

1) Have you verified the cable integrity between the 1734-232ASC and the printer? How long is the run? Is it all shielded correctly? Are you using the correct GND/SG? Is the environment electrically noisy?

2) Have you checked that the printer is earthed correctly, and has the correct DC-/0V if any?

3) Have you checked that the PointIO installation is earthed correctly, and has the correct DC-/0V connections?

4) Can you swap the working printer and new printer to check if it works on the original 1734-ADN setup?

Does the printer keep a fault log? You should be able to see what's causing it to reboot, short of the system crashing.

Thanks for your reply Jeev,

While you replied, I was out verifying the same things that you have suggested.

1) The cable looks good and the pin outs are proper. The shielding is sound and the environment is not noisy at all. The cable length is less than 2 meters.

2) The printer is earthed. We supply 240Vac to the printer and it has its own DC power supplies on board.

3) The point IO installation may NOT be earthed properly, but the DC voltage is correct. I am going to head out after my morning meetings to verify the earth connections.

4) At last resort I will swap the working printer and the new printer out. It is a bit of a job to do this, but it will have to be done.

The printer does not keep this sort of fault log that I am able to interrogate. The techs from Domino suggest that I have a problem with the format of the message, but this is not the case. They are getting back to me with more information hopefully today.

I am just about ready to try anything, so today I am going to make a new serial cable and try that out. I will check the earthing of the point IO. If they fail, I will pull the printer out and install it on the working installation. I have a feeling that I might be facing difficulties with firmware / hardware revisions and updated main controller boards on the printer. There must be something in the quality of serial signal that is OK for my laptop, but not OK for the printer. I am not sure how to test this further.

Cheers

Which Domino is it? Are you using Merlin, Dynamark, or something else? I have some literature for A, C, G and M series printers/labellers.

Check your message file, if it has become corrupt, or it is wrong, it may be causing some issues. Check all the variable names in your message file, and any constraints the variables have on them (Length, format, and so on). Actually, check the integrity of all your files. Were these all copied over from the old printer to the new one? Have you made sure all the fonts and other resources are available and working on the new printer?

Is the firmware/OS on both printers the same?

It is a Domino G series, previously the Apsolute V1 printers. I have four Apsolute V1's here that I talk to both over TCP and Serial connections.

Originally I checked the message files as I have had corrupted messages cause me grief in the past. I created a new message and changed the vtext fields around, all to no avail. I pretty much tested everything and every combination that I could think of.

So this afternoon after a productive day of meetings I went over there to rehash the earthing integrity of the system, the power supply wiring, and the serial connections again. I tried one new cable, and then another much longer one just because I could, but was not successful.

I got some directive from Domino in China about testing the baud rate and that I should increase it from 9600 to say 38400 for example in case it was a timing issue. I had already tested this, but I thought what the heck.. let's try this again. It didn't work again. So I thought I would try the faster baud rate with a msg that I could send at 9600... and that didn't work either!! What the heck?? I then changed the baud back to 9600.. and the message went through. So I retried the message that reboots the printer, and it still rebooted the printed.

I changed the baudrate to 48008N1... sent the variable text message.. and the damn thing worked!!

I have never in my life have to slow down the baud rate to anything less than 9600 to have something work. My other Apsolute printers are talking 9600 no problems. This one works on 4800bps. I am officially none the wiser.

The earthing of the system checks out ok, I do not believe that I am missing anything, but for whatever reason I had to slow the baud rate down when talking through the 1734-232ASC module.

I am trying to find out what dynamics would affect this.

Yeah, a higher baud rate has always caused more problems than it has solved for me. I'm surprised Domino suggested using it.

Have you got a scope? It would be interesting to see what's happening to the signal between the 4800 and 9600 rates. I'm wondering if it's waveform related or timing related.

Random question: Is your cable shield only connected on one side? For example, PointIO terminals only?

Perhaps the next installation should be ethernet? I have used Prosoft GECs, EN2T(R), EWEB and CompactLogix to talk to Domino printers with open socket.

Our scope here has long been out of action, so that one is out. We mostly just fly by the seat of assumption when it comes to things like this unfortunately.

The shield on the serial cable is only connected on one side, but it is on the printer side.

I have used the Prosoft GEC card with the Domino printers in a ControlLogix rack, and honestly this is why on this one I went back to serial. On my ethernet installation, every now and then the GEC card stops talking along the backplane to the processor. Only solution is to re-seat the module / cycle power to the rack. I put these in back in 2009. I spent weeks back and forth with Prosoft saying it was a Rockwell problem and Rockwell saying it was a Prosoft problem. Now we just live with the occassional comms loss fault.

Do I understand from your post that it is possible to send an ASCII string straight out of the EN2T card to the printer?? Pardon my ignorance!

Crammed77 said:

Do I understand from your post that it is possible to send an ASCII string straight out of the EN2T card to the printer?? Pardon my ignorance!

Click to expand...

This is how we now do it for any printer or check-weigher that will do ASCII over Ethernet. Any of the cards that support open socket can do it (EWEB, EN_T(R), 5370, 5580, and so on.). We originally used an MVI69-GEC with a G-Series printer. This was quite unpleasant, as you discovered. Since then we have used an L33ER with an A-Series, and I'm about to do an L33ER with an M-Series.

There are lots of posts here, and examples in the Knowledgebase/Literature about using open socket messages. The code can be a little cumbersome when fully implemented, but once it's working and tested, just make an AOI or copy/paste.

Wow, thanks for the heads up!! I am only really exposed to what I have done here on site so it is usually only when I stumble across something like this in a forum that it opens my eyes.

I will definitely look into learning more about this after I knock a few more jobs off the list.

Thanks again!