PLC-programming problems

[Peter Nachtwey]

You have the wrong tool for the job.

Get a decent servo controller where you can specify the acceleration, deceleration, velocity and destination in one command at the the control do the rest. You should not need to do all the internal calculations yourself. To do so is a waste of your time. Target or trajectory generators are very tricky.

 

[soder]

Hmmz.. we have specified the initial frequency, maximum frequency, acceleration speed, and the coordinates of the target in the PULSE LINEAR DUT.

DUT (PULSE LINEAR):
ControlCode := 16#1010,
InitialSpeed := 10,
MaximumSpeed := 100000,
AccelDecelTime := 300,
TargetValue_X := 0,
TargetValue_Y := 0


Or isnt this what you mean with "let the servo controller do the calculations".




All though... we have decided to put the "linear units" on hold for a while, while we focus on the communication between PLC and our PC.

We made a small example program using the F159_MTRN, but now we've encountered some problems. We have read the manual several times and we think that this would work but it doesn't.

We're trying to set the PLC into "general purpose mode" so
that we can send/receive data via the COM port. But it
wont get into that mode. We set 16#8000 as the number
(transmissionMode, see below) as we have read but it still
doesnt change into general purpose. We have also changed
it directly in the System Register but it didnt work
either. We're checking the R9032 which should be turned ON
when we're in general purpose mode, but it never is.

We cant "debug" the code while we're testing the
communication since we have to "disconnect" FPWinPro from
the PLC and connect HyperTerminal instead. So we used the
output signals Y5-YA instead. Then we could see "where" in
the code we are (or have been).

Perhaps any one here could help us finding out what wrong we have done? Meanwhile we will try to fix it ourselves ofcourse.


Here's the code:

(* Communication test. Tests both reception and 

transmission over *)

(* the COM port 1. *)

(* JP & AS, 2004-05-19 *)



(* set length of reception *)

textArray[0] := 1;



(* if not general purpose then change *)

if not R9032 then

	(* change into general purpose (code 16#8000) *)

	F159_MTRN(s_Start := dummy, n_Number := 

transmissionMode, d_Port := 1);

	Y5:=TRUE;

end_if;



(* general purpose *)

if R9032 then

	Y6:=TRUE;

	(* receive length bytes from COM 1 *)

	F159_MTRN(s_Start := textArray[1], n_Number := 

textArray[0], d_Port := 1);

	(* reception done *)

	if R9038 then

		receptionDone := TRUE;

		(* send text *)

		Y7:=TRUE;

		F159_MTRN(s_Start := text[1], n_Number := 

text[0], d_Port := 1);

		if R9039 then

			transmissionDone := TRUE;

			Y8:=TRUE;

		end_if;

		(* clear to make another reception *)

		(*F159_MTRN(s_Start := dummy, n_Number := 

0, d_Port := 1);*)

		(* change transmission mode *)

		F159_MTRN(s_Start := dummy, n_Number := 

transmissionMode, d_Port := 1);

	end_if;

end_if;





(* debug/watch *)

receptionDone := receptionDone;

transmissionDone := transmissionDone;

textArray[1] := textArray[1];

DTLength := DTLength;

DTText := DTText;

Y9:=TRUE;



count := count + 1;

 

[Laurent]

Soder,

Looks like you're not far from something running.

* DUT (PULSE LINEAR):
...
InitialSpeed := 10, <-- Set here the highest values you can
MaximumSpeed := 100000, <-- As far as I know the composite speed cannot be that high
...

(* falling edge at x- or y-axis, or first time *)
IF DFN(R903A) or DFN(R903C) or runonce THEN
runonce := FALSE;
(* change direction *)
ChangeTargetXY(DUT_In:=dut,DUT_Out=>dut);
...

- "IF DFN(R903A) or DFN(R903C)" should become "IF DF(NOT(R903A) AND NOT(R903B))".

* EV_Channel2 AT %MD5.90105: DWORD:=0;
TV_Channel2 AT %MD5.90107: DWORD:=0;

- Confusion in addresses: 90200 and 90202 will help you to succeed at 100%.

* How do we tell the system where the (0, 0)-point is?
- The Home function is an important part of the job. You could also home at coordinates <>0.

* Sensors: only use X2/X5. The associated functions are all built-in. There is no programming there. As previously stated, check the axis elapsed values and perform a "near home" through DT90052 (slowing down your axis). You keep two inputs free for other assignments.

* Over-travel sensors: re-read the previous posts. Don't take a chance to damage your axis. Prefer wired safety functions switching your power off (or the drive's power stages).

* We cant "debug" the code while we're testing the
communication since we have to "disconnect" FPWinPro from
the PLC and connect HyperTerminal instead...
- Perhaps there is a confusion here. The programming port is called TOOL port and not COM port. This label usually refers to the communication cassette including one or two additional ports.

Whether you decide or not to use a communication cassette, why not choose the Computer link mode? It's easier for your computer to write into the PLC by using the protocol (only one request to implement for coordinates changes). There is no program required in the PLC. Notice: the protocol is available on both TOOL and COM communication ports. See your manual. Ask for details about this Protocol. Documentation available upon request. See your distributor. Tests can be performed with HyperTerminal.
A tool called "Control CommX" is also available for interface's programmation in VB and easy access to NAIS FP products.
For tests: have a look at http://www.kepware.com and download a demo version of their NAIS/Aromat/Matsu OPC server.


Laurent

 

[soder]

Thanks again!
We had a free day today so we'll check this out first thing in the morning - but I'm still a bit confused about the sensors, you say it only takes the wiring and no programming? How do we know if they work and how are they suppose to work? Does the pulses to the linear units stop automatically when a sensor is "triggered" or is the power just cut off?

If we take an small example.
Our unit is at position 50 and the end-sensor is at position 70. If we make a command that tells the unit to go +50 and then -50, what will happen?

Will the sensor go +20 and then - 50, while the program think it's on position 50 or will it know that it's suddenly is on position 20?

OR, will the sensor go +20 and then - 20 because it "understands" that 30 of the pulses aren't supposed to make the unit travel?

OR, will the sensor just stop att position 70 because the power was cut off when the sensor was triggered?


I hope you understand the example

Many thanks,

//Andreas

 

[soder]

Hi.


We have been reading alot about RS232C and RS485 and COM and TOOL port etc.

Is it correct that COM port is a 9-pin parallell trapezoidal port on the PC and the TOOL port is a round 5-pin port on the PLC? If this is correct, then it's what we have.

We have also a converter between RS232C and RS485 in form of a cable. (We know that it works (or hope) because we can download our program to our PLC with it.)

Now on to our problems:

First: We're having difficulties with debugging since we're using FPWinPro 5 to debug. We're trying to send data to the PLC from the PC via HyperTerminal (and vice versa) but then we'll have to "disconnect" on-line mode. And then we cant debug anymore. Is there another way of doing this "debugging"? We have been using outputs (X6-XB) to see where in the code we are (e.g. X6 := TRUE but we're having troubles to see values of registers etc.


Second: We can't get the communication to work. We've tried to change mode to "general purpose" but with no success. We have also changed values in registers 410-417 to different COM-settings but no luck there either. We have used M159_MTRN to change mode, receive data, send data, but nothing. We have "debugged" R9032, R9038, R9039 but never have we seen them change.
We saw the SYS1 in the manual but haven't understood it completely. Haven't we already the "correct" settings in the registers 410-417?
We also have some problems with understanding how the M159_MTRN uses the registers 416 and 417 ("starting address of receiving buffer" and "receiving buffer size").
Finally we tried to change the values of R9032 but it wouldnt work either. Now we're gonna take a break over the weekend and perhaps we will figure it out on monday.

If you have any samples of how serial communications between a PC and a PLC then we would be very happy to get it.

Thanks, and have a nice weekend.


// Johan and Andreas.

 

[Laurent]

Andreas, Johan,

you say it only takes the wiring and no programming? How do we know if they work and how are they suppose to work? Does the pulses to the linear units stop automatically when a sensor is "triggered" or is the power just cut off?

I was only refering here to the home input in F171 / home mode. But as for your over-travel sensors they should be used as an externally wired safety system. In case you reach them, switch your power off, cancel your process and continue by asking the operator for a homing cycle. In your example select the third answer but consider in addition that the current position is actually lost.

Is it correct that COM port is a 9-pin parallell trapezoidal port on the PC and the TOOL port is a round 5-pin port on the PLC? If this is correct, then it's what we have.

It's correct... but not enough! Obviously there is a so-called serial COM port on your computer. I was asking for a COM port in the PLC. Consider the left side of your PLC. There are two removable panels. The biggest of them may be replaced by a communication cassette (see your manual) providing additional COM port(s) RS232 and/or RS485. If one of these cassettes is in place, you may see a green connector and the PLC power supply connector side-by-side. But I guess there is no such tool in your PLC... You would have mentionned it earlier. These additional ports are called: COM port(s).

We have also a converter between RS232C and RS485 in form of a cable. (We know that it works (or hope) because we can download our program to our PLC with it.)

By the way there is not RS232/RS485 converter to be used with the FP-Sigma programming port (TOOL port). Your cable is basically a RS232 one.

Now on to our problems: First... Second...

Since there is no COM port on your PLC all what you did is... OK I don't say a word anymore!

Available solutions:
1) TOOL port access. Built-in protocol (such as FP-Win but public part only). The MEW protocol is called MEWTOCOL. MEW for Matsu Electric Works. Various versions or parts depending on the purpose and context. In this case MEWTOCOL.COM. Your computer is Master. No program required in the PLC.
2) COM port access (communication cassette required) in Computer link mode (meaning MEWTOCOL). Same as above but keeps the TOOL port free for simultaneous programming/monitoring.
3) COM port access in General use mode. It's the way you found out but couldn't test. Program required, not very useful in your project.

I strongly suggest that you choose the second solution but the first one will run without further expenses. I dug out the attached files from my library: one in english/one in french. Look at the WCC command for data writing. All can be tested in terminal mode. Programming tip: there is a joker chain ("**") for the BCC (useful in terminal mode tests). WOW... we are playing here with dinosaurs. I didn't use them since the era we wrote programs in DOS terminal environments - Smarterm, Procom+... Don't even know how it works with Sigma but will test immediatly.

Laurent

 

[soder]

Thanks for the dinosa... MEW protocol. We already had a newer but we never took any notice of it (since we didnt understand what it was for).

We've been using HyperTerminal to communicate from PC to PLC and we have been able to read data registers but not write them.

We have declared a double word variable in DT90028 (the manual said that it wasn't used):
variable AT %MD5.90028: DWORD:=0;

And we read it like this:
%01#RDD9002890029**
Answer:
%01$RD0000000016
(It's correct.)

But when we try to write to it:
%01#WDD90028900280001**
We get this answer:
%01!6102
("Data Error. The specified data format was not correct.")

Don't even know how it works with Sigma but will test immediatly.

Have you had any luck with it?

 

[Laurent]

Not surprisingly you're rejected when attempting to write DT90028 or above: here are the system registers (Reserved area. Some words may be overwritten but your manual is clear about DT90028: N/A). Try within the range DT0~DT16000. It works.

Laurent

 

[soder]

Update:

We have made a new function in our C++ program that takes two "pulses" as inputs and returns the instruction that will be sent to the PLC.

The instruction is "set word"-instruction which sets 4 words into the PLC's memory
eg. %01#WDD0090000903A0860100E0930400** (+CR)

char * GetInstruction(int xtal, int ytal)

{

	char * instruction = new char[37];

	char xtext [9];

	char ytext [9];

	char xswap [8];

	char yswap [8];



	// transform coordinates from dec to 8-byte hex

	sprintf(xtext, "%08X", xtal);

	sprintf(ytext, "%08X", ytal);



	//position swap x

	xswap[0] = xtext[6];

	xswap[1] = xtext[7];

	xswap[2] = xtext[4];

	xswap[3] = xtext[5];

	xswap[4] = xtext[2];

	xswap[5] = xtext[3];

	xswap[6] = xtext[0];

	xswap[7] = xtext[1];

	//position swap y

	yswap[0] = ytext[6];

	yswap[1] = ytext[7];

	yswap[2] = ytext[4];

	yswap[3] = ytext[5];

	yswap[4] = ytext[2];

	yswap[5] = ytext[3];

	yswap[6] = ytext[0];

	yswap[7] = ytext[1];



	// add type of instruction and memory areas

	instruction[0] = '%';

	instruction[1] = '0';

	instruction[2] = '1';

	instruction[3] = '#';

	instruction[4] = 'W';

	instruction[5] = 'D';

	instruction[6] = 'D';

	instruction[7] = '0';

	instruction[8] = '0';

	instruction[9] = '9';

	instruction[10] = '0';

	instruction[11] = '0';

	instruction[12] = '0';

	instruction[13] = '0';

	instruction[14] = '9';

	instruction[15] = '0';

	instruction[16] = '3';

	// add word to be written into the memory areas

	for(int a=17; a<25; a++)

	{

		instruction[a] = xswap[a-17];

	}

	for(a=25; a<33; a++)

	{

		instruction[a] = yswap[a-25];

	}

	// add the end of the instruction

	instruction[33] = '*';

	instruction[34] = '*';

	// add Carriage Return

	instruction[35] = 13;

	instruction[36] = '\0';



	return instruction;

}

We now can type different x- and y-pulses (which corresponds to coordinates) and the linear unit moves there.

We've been testing HSC control commands. But havent got them to work satisfyingly.

We try to stop both axis with the coordinates (0,0) otherwise we move the unit to the input coordinates.

(* start *)

if coordX = 0 and coordY = 0 then

	HSC_ControlCode := 16#0909;

elsif coordX <> prevX or coordY <> prevY then

	(* Disable count: 16#2 (0010) *)

	(* Stop pulse output (clear instruction): 16#8 (1000) *)

	HSC_ControlCode := 16#0808;

	dut.TargetValue_X := DWORD_TO_DINT(coordX);

	dut.TargetValue_Y := DWORD_TO_DINT(coordY);

	HSC_ControlCode := 16#0000;

	F175_SPSH_LINEAR(n:=0, s:=dut);

	(* Disable count: 16#2 (0010) *)

	prevX := coordX;

	prevY := coordY;

end_if;

We try to stop both axis as once, but it wont. Dont know why. We're using Ch0 and Ch2 (which corresponds to bit 0 and bit 2).

Dont like those control instructions. They wont do what we want. Well.. some more testing and we'll figure them out.

We'll soon be back with some more problems.


// Johan and Andreas.

 

[soder]

We've encountered a problem that we cant figure out.

We use F175 with 2 axis (Ch0 and Ch2) but we can only
control the first one with the DT90052 register.

code:
HSC_ControlCode AT %MW5.90052: WORD:=0;

We use control commando 16#0008 to command the Ch0 (while
moving, we can stop the axis and give it a new target).
But when we try to command Ch2 with the command 16#0800
nothing happens. We've tried all combos 16#0008 (only
controls the first axis), 16#0080, 16#0800 and 16#8000
(crasches the PLC) but none seems to work.

code:
e.g. HSC_ControlCode := 16#0008; (works with Ch0)
or HSC_ControlCode := 16#0808; (works with Ch0, but not Ch2)

<-- we think that the last should work due to our manual.

What are we doing wrong? Are we not thinking correct? Or
we using the wrong registers? Anybody that knows?

 

[soder]

We found the error.

HSC_ControlCode := 16#x000; <-- x = channel

HSC_ControlCode := 16#2008; <-- solves our problem.

Strange that the manual didnt mention this. Anyway, we can now move the linear units from target to target without stopping (Suggestion 3).

And we have done some major thinking about Suggestion 4.