qj71c24n-r2 non procedure protocol problems

I have writen a serial driver for the Mitsubishi QJ71c24n-r2 module. The driver controls a pump, that requires serveral commands. The software has been a nightmare to develop. I can not
get control of the timing. The code runs at a slower scan rate
but when set to run at .2 ms, does not run. I have interlocked
everything there is to, but still get errors.

I think the solution is to use something like Deco, so the
each command is a state. When I plug in Deco control of the
code, the communication stops completly. I have also tried
MCR commands with the same result. Without any way to force a
state machine, the code runs wild, getting stuck in one command
after another. When dugging, I have noticed that two command bits
are on at the same time, even though interlocking is in place.

Has anyone writen a similar piece of software, and it so, how
did you get control of the softare? It is supposed to send out
a command, wait until the "done" bit is set from the INPUT statement, turn off the bit that controls the command, set up
for a different command, set another bit, and repeat the process
until all commmands are sent. Each command is interlocked, and
each command uses the system bits to determine when the OUTPUT
and INPUT are done. The INPUT is triggerd by X3.

The communications are half duplex and should be pretty straight
forward.

I am considering trashing the code and attempting to use the
framing method of communicatons, but the manuals for this are
horrible and convey little or no information.

Any code examples or ideas on how to make this &&%%$ driver
work?

Tom Kazakoff

Protocol specification

I might be able to help as I have written code for this comms module before. To be able to understand what you are trying to achieve, it is best to start with the format of the telegrams that are sent between the PLC and the external device. Do you have a document that describes the format of the telegrams? If you do perhaps you can send it to me. If not, just a few notes on the basic layout of the telegram would be helpful (e.g. STX, STATION#, INSTRUCTION#, DATA, ETX, CHECKSUM).

Regards,

Alastair

Serial comms on 0.2ms seems a bit quick to me... The commands might not be able to complete that fast.

With this module, the communications and the CPU scan are asynchronous. The CPU tells the comms module to send a telegram and the comms module tells the CPU when it has finished, or (if receiving a telegram) the comms module tells the CPU a telegram has arrived and then the program in the CPU can read it.