Step7 - Timers (again!) and other things

I've got to scan a bar-code using a Cognex DataMan scanner. For reasons of convenience (my convenience!), I want to run the complete data acquisition in an FC which is called in one Step of the main program - i.e. this FC will run to completion in one CPU cycle. In itself, this is not a problem - if it weren't for the fact that I need a Trigger Impulse to start things off and I need a variety of other Timers to monitor potential fault conditions.

Now (I believe) I know that Timers run asynchronously to the CPU cycle, so I assume that something like the following code ought to work:

D_1: NOP 0; //Get character 1
CALL "Get DataMan Data" (
Start_Byte := "MW_DataMan_Next_Byte");
SET
R "M_FC1_First_Time_Data";

L 2; //Toggle RR Bit in KL6001 Control Byte
T "PAB_KL6001_Control_Byte"; //write output Byte directly
W_1: NOP 0;
AN "M_KL6001_Status_RA"; //warten bis RA gelöscht wird
JC D_2;
A "M_FC1_First_Time_Data";
L S5T#100MS;
SD "T_Data_holen";
SET ;
S "M_FC1_First_Time_Data";
A "T_Data_holen";
JCN W_1; //warte bis RA toggles

S "TP1".Stoerung199; //Data transfer Timeout
S "KV".BA.Sammelstoerung;
BEC ; //Exit

D_2: NOP 0; //Get characters 2 - 4

Question 1 - is this assumption correct?

What I'm less sure of is how to drive my pulsed output. Since I need to write the outputs directly, that means I need to write (at least) a full Byte at a time. This means I need to read the current state of the output Byte and OR it with my Trigger Bit. I know I can read the output Byte in the Process Image (and since I can't find anywhere where the Outputs are being directly accessed, at present, that would probably be enough), but:

second question - is it possible to read the Peripheral Output Byte PQB1 directly?

Cheers

Roy

Just to be a bit more precise, this is what I'm doing and it's not working.
code:
NETWORK
TITLE =Trigger Camera
NW_2: NOP 0;
A "M_FC1_First_Time_Impuls";
L S5T#10MS;
SP "T_DataMan_Trigger_Impuls";
SET ;
S "M_FC1_First_Time_Impuls";
A "T_DataMan_Trigger_Impuls";
JCN NW_2;
L QB 1; //Get current state of output Byte
L B#16#20; //Set Trigger Bit
OW ; //and OR with rest of outputs
T PQB 1; //Transfer Byte directly to Periperal Output
L_Tr: NOP 0; //Wait for end of Trigger Pulse
AN "T_DataMan_Trigger_Impuls";
JCN L_Tr;
L QB 1; //Get current state of output Byte
L B#16#DF; //Clear Trigger Bit
AW ;
T PQB 1; //Transfer Byte directly to Periperal Output
NOP 0; //Wait for IO / NIO reply
L "PEB_Beckhoff_Eingänge"; //PIB1
T "MB_DataMan_Inputs"; //Save in Merker_Byte MB605 for Bit access
CLR ;
ON "M_DataMan_IO"; //M605.4 - OK Bit
ON "M_DataMan_NIO"; //M605.5 - Fault Bit
JC R_0; //Go read first Data Byte
A "M_FC1_First_Time_Trig";
L S5T#50MS;
SD "T_Trigger_KL6001";
SET ;
S "M_FC1_First_Time_Trig";
A "T_Trigger_KL6001";
JCN L_Tr;
S "TP1".Stoerung197; //Trigger / Reply Timeout
S "KV".BA.Sammelstoerung;
BEC ; //Exit

NETWORK
TITLE =Read Data from Cognex DataMan via Beckhoff KL6001
//Nach dem Trigger ist ein explizit RR (Read Request) über das Control Byte nicht
//nötig, das erste Data Byte ist schon vorhanden (immer nur ein Byte).
R_0: NOP 0;

/code

The second Timer seems to be working okay because I'm getting error 197 on the OP and the CPU isn't going into STOP because of cycle time, but I'm apparently either not setting the Trigger output or not getting the IO / NIO inputs back.

Edit: What are the correct commands to get the code to hold its format, so you can read it comfortably?

Is this barcode scanner connected over a serial module ?

I've tried this code in the simulator and extended the timers so I can see the output follow the first pulse timer - it does. (I have to clear "M_FC1_First_Time_Impuls" and "M_FC1_First_Time_Trig" before calling the FC so I'm assuming this is done elsewhere).

Could the Profibus update time be close to 10ms so the Beckhoff isn't actually seeing a 10ms pulse to trigger it?

To get the code to hold its format the syntax is

{code}
/// your code here
/// and here
{/code}

but replace the curly brackets with square ones !

Is this barcode scanner connected over a serial module ?

Click to expand...

Yes, it's connected to a Beckhoff RS232 KL6001 Terminal Block (the DINs and DOTs are also via Beckhoff terminals, all) connected via a Beckhoff BK3120 bus coupler to the Profibus Net. The fact that this is my first encounter with Beckhoff equipment hasn't exactly helped. Their documentation is occasionaly a little sparse!

I have to clear "M_FC1_First_Time_Impuls" and "M_FC1_First_Time_Trig" before calling the FC so I'm assuming this is done elsewhere

Click to expand...

This is done at the start of NW1 - all "First_Time" markers.

Could the Profibus update time be close to 10ms so the Beckhoff isn't actually seeing a 10ms pulse to trigger it?

Click to expand...

I must admit, I hadn't thought about this, in my first attempts, I had the pulse length significantly longer, but I had the address wrong (the "16"er Bit addressed as B#16#16 instead of B#16#20). Then during playing around in the VAT, I noticed that the Cognex actually triggers on the falling edge of the pulse, not the rising edge and since I don't want to push the cycle time too far, I promptly shortened the pulse to 10 ms. According to the Cognex blurb it can run at up to 60 Pictures/sec.

I'll need to check on Monday, when I'm back on site, but we're running the Profibus at 12 MHz and although there must be at least a dozen slaves on the Net, in the back of my mind I seem to remember seeing that the Profibus cycle time (or whatever it's officially called) was around one or two ms. Still it's definitely something to check out - apart from that, I've no idea what the latency of the Beckhoff K-Bus is, all in all, something worthy of further investigation.

I'm always impressed how easily you seem to manage to check things out with PLCSim. In my current company I no longer have it available (cheapskates?), but my previous attempts to use it weren't particularly successful. In particular I found the "recorder" function a disaster - a potentially extremely useful function was ruined by the fact the recorder "photographed" the current states Byte-wise, which means that if you group your IO for a particular plant or machine area together (which because of my process control background in chemical plants, I tend to do) you can't interact with a recorded run, because when the next recorded Byte runs it kills the Input or Output you've just modified!

I'll get back on Monday when I've had a chance to double check the Profibus details.

Cheers

Roy

The profibus doesn't sound like it's the problem with a dozen slaves at 12M. Are there any analogues on Beckhoff ? (the Beckhoff ones I've used don't scale the same as the siemens units - just thought I'd mention it)

I've never used the recorder facility, i just work with PLCsim as if it's a real plc.

There are a couple of AINs and AOTs on the Beckhoff backplane, but the KL6001 is in the first slot after the BK3210, so I would expect it to have a fairly fast response - having said that, I've no idea how the BK3210 communicates with the Terminal blocks on its K-bus. I haven't had to change anything with the analogue units, but I seem to remember from my general scanning of the Help files, that you're right about the scaling being different.

Problem solved...

At least the problem with the Trigger Pulse is solved. I'd forgotten to include a Timer to cause a delay after initialising the Camera before issuing the Trigger Pulse. As a result the Trigger Bit was being set before the Initialisation was finished and consequently was being ignored.

I've still got a few other problems here, but so far it's not too clear exactly where the problem lies, so I can't come up with any sensible questions yet - that may change!

Thanks for the verification that the problem lay elsewhere.