QJ71C24N-R2

[titanspark76]

  Soon I'm going to be trying to communicate with a torque tester using the QJ71c24N-R2 module on a Q10CPU. This tester is typically meant to send data to a software program and inputted on an excel spreadsheet. I talked to the company and they are sending raw data out via RS232 so I'm hoping I can capture it.

  I've read through some old posts and it appears it is required for the C24 module to receive data that terminals 1,4,6 be shorted and 7,8 be shorted is this correct? In one of the examples in the C24 manual it shows 4,6 shorted without 1, but I'm not sure if that is correct for the application. Attached are screenshots of the torque tool settings and a connection guide on the C24. Currently I'm thinking on the C24 side of cable to short 4,6 short 7,8 . From the torque tool to the C24 module 2-2, 3-3. Does this sound like it will work? 

 

 

 

 

 

 

[Gambit]

Why not just use MX Sheet and delete the sending out of RAW data part of the program?

[titanspark76]

I'm not that familiar with MX sheet, but I believe MX sheet uses a PC and transfers data between an excel spreadsheet and the PLC. In our setup there will be no PC. 

[kaare_t]

I always short 1,4,6 and 7,8. That way you're "sure" (it's only handshake signals so it doesn't hurt to short them).

Regarding the wiring, it all depends on how the torque tool is configured. If it has a "PC" port it will be 2-3, 3-2 and 5-5. If it's a "modem" port it will be 2-2, 3-3 and 5-5. My guess is that it's a "PC" port. The C24 is the same as a computer port (that's why you have to cross them if the torque tool is also a "PC" port).

If I understand you correctly, the torque tool is supposed to get data from an excel sheet application, but you want to send it from the PLC instead? That's why you are eliminating the computer? And you don't want to collect data from the torque tool, only to feed it data from the PLC? Correct?

[titanspark76]

The exporting to excel was a typical application for the unit, but not our application. We did receive the unit and can see the data with hyperterminal so should have a fighting chance. I haven't used RS232 communications much before so when I started researching I came across some posts here recommending to short the terminals mentioned and wanted to make sure I was getting off to a good start. So since the C24 is the same as a computer port if I'm able to see the data via hyperterminal with a straight through cable (which I am) does that mean this is what I should use to the C24?

[kaare_t]

Yes, use exactly the same cable as you use with a computer - but you'll need a gender changer on the C24 side (since it uses a female DB9, while a computer uses a male DB9).

The C24 port is exactly the same as the computer port except the gender, so use the same cable, but with a gender changer, or make a suiting cable.

Sadly, when Mitsu made the C24 card they decided (who knows why) to use a female DB9 (which is generally used by modems) instead of a male DB9 (which is generally used by computers). This can be very confusing since Modem<->PC uses a straight cable while PC<->PC uses a crossover cable. But in the end the C24 acts like a computer port, hence use the same cable wiring as you do with your computer.

If you can see data coming via HyperTerminal that's a good start. For the C24 card you will need some programming effort. What kind of SW and language are you using to develop your code?

[titanspark76]

GX works2

[kaare_t]

If you're using "Structured Ladder" you can download FBs (Function Blocks) from Mitsu's website for C24 NoProtocol communication which basically gives you the data as an output. If you're using "Simple Ladder" you'll have to go through the manual of the C24 and find an example of NoProtocol communication. It's pretty straight forward, but it's easier with FBs.

[Gambit]

@Kaare_t is right the FB are easier but even if you do not want to use FB's all you do is set the end character if you have one and then use the G.input en G.ouput instructions.
All the comm parameters are set in the special function utill.

Its pretty straight forward

 

Edited December 23, 2016 by Gambit

[titanspark76]

The project is simple ladder. I've looked at several different sample code and I'm attaching some code that I'm hoping will work (please advise). Since I'm wanting to get the data anytime it is sent I only setup the G.INPUT. 

[Gambit]

Well. The code looks oke accept for a one thing.:

1) The G.INPUT start address should be U0A instead of U0A0

The string being received is this with an end character or Fixed length?
If it is with an end char is this CrLF (Hex0A0D) ?

 

 

Edited December 27, 2016 by Gambit

[titanspark76]

Thanks for the help. I never did have any luck getting the data using the G.input even after fixing it to U0A. I was able to get the data using the Z.BUFRCVS instruction which is suppose to be used in an interrupt program, but I simply held it always on (-----||sm400-------------------------{Z.BUFRCVS U0A K1 D1500}). Don't you love it when you beat your head against the wall trying to figure something out and in the end one line of logic is all it takes. 

[Gambit]

Haha So True

[WR]

On 12/23/2016 at 9:23 PM, kaare_t said:

If you're using "Structured Ladder" you can download FBs (Function Blocks) from Mitsu's website for C24 NoProtocol communication which basically gives you the data as an output. If you're using "Simple Ladder" you'll have to go through the manual of the C24 and find an example of NoProtocol communication. It's pretty straight forward, but it's easier with FBs.

Could you give me the link for the website mentioning above?

[kaare_t]

https://eu3a.mitsubishielectric.com/fa/en/mymitsubishi/download_manager?id=4692&tab=3