PCo 15 Which Correct Source System

[Former Member]

Hi There,

We are configuring a completely new PCo 15 installation. We setup the following Source System:

Connection Type: Socket Agent

Name: TestScales

Remove Terminator when receiving data: Checked:

Check Connection: Checked

Name: Populated

Address: Populated

Port: Populated

Terminator: \13\10

Max number of Retries: 0

Retry Interval: 0

I setup my destination system as a SAP NW RFC Server, the Agent Instance with Port Type of SAP NW RFC Server and I also setup the notification.

I can connect to the scales with no issues, I can send a command to the scale through PCO15 using my test program, but it appears when I use this setup, the agent doesn't wait for a response from the scale when I send my command. I have a TCP\IP Client that I can send commands to the scale and when I send the command to the scale from the TCP\IP client, I get the values returned correctly.

Am I using the correct Connection Type for this scenario?

Thanks for your help!

Colm

[Former Member]

Hi Guys,

We have managed to get the PCo15 agent talking to the scale. The issue was caused by the fact that we had the "Check Connection" flag set which was sending a blank command down to the scale. This blank command resulted must have caused the scale to enter into a status that stopped it from receiving further requests. Once we took off that "Check Connection" flag, the scale now receives our commands.

We are able to send down a reset statement which sets the value on the scale to 0.00 which is great, but we still have the issue where we are not getting results back from the Scale. The error log now looks as attached. The value of 0.00 kg is correct as I have just reset the value on the scale but for some reason it's not coming through into ECC.

TestAgent_2015.10.07_13.16.45.csv.zip

[former_member196557]

Hi Colm,

After review or your log, PCo is attempting to send the Notification payload to the RFC destination and getting these error messages in the log:

"MessageDeliveryException: [severity = Fatal] Message could not be delivered InnerException RfcAbapException: ERROR_BADI_IMPL    at SAP.Manufacturing.Connectivity.RFCDestination.Send(NotificationMessage message)

RfcAbapException when executing ABAP function module S_PCO_RFC_EXECUTE_RECEIVE_EVNT|"RfcAbapException: ERROR_BADI_IMPL    at SAP.Middleware.Connector.RfcConnection.ThrowRfcErrorMsg()

Sending of notification failed: Notification [notTestAgentE6R] to destination [SAPE6R]. [ERROR_BADI_IMPL No active BAdI implementation ]

Seems to be something missing on the RFC end.

Regards, Steve

[Former Member]

Hi Steve,

I'm not sure if this is correct as it doesn't "feel" correct but I have had to create an implementation of the S_PCO_ES_BADI_HANDLE_NOTIF. I didn't see any documentation saying that I needed to do this, but I did. Once I created an implementation of that, I had to implement my version of the method GET_CLASS_NAME.

In GET_CLASS_NAME, I flag a new class that I want to get called to handle the notification coming back from PCo which I call ZCL_STORE_NOTIF.

Since the command to SEND the notification to the PCO is completely separate from the notification sending back to ECC. In order to use this, I had to implement a ZTABLE which will store the message coming back from PCo. This table is keyed by the unique identifier that is on the message.

In my calling program, I have implemented a wait that will check the table for this unique identifier and then once it finds the entry in the table. It will delete it from the table. So in effect my ZTABLE is like a temporary holder for the messages.

As I said, it doesn't "feel" correct so if anyone has anything better I'll gladly try it but as it stands, my connection is now working.

Thanks for the help!

Colm

[former_member185280]

Turn logging up to verbose and see if you are getting any response from the scale. I have had issues in the past with determining the correct terminator.

I have also had issues with the Check Connection functionality causing some systems to drop the connection so try disabling it to troubleshoot.

Regards,
Christian

[Former Member]

Hi Christian,

I have the logging set to verbose and the PCo agent is doing a connection test every 30 seconds and returning a message "IsConnected returned TRUE" so I think we can say it's connected fine.

I also turned off this check and did my test but still the same response.

Thanks for the input!

Colm

[pieter_conradie2]

Hi Colm,

To send message from ECC to your socket agent you must convert it to HEX thus <CR><LF> will equate to '&#13;&#10:'

Regards

Pieter

[Former Member]

, I hope you don't mind me tagging you directly but I have seen you comment on similar questions before so I'd really appreciate your input if you had any. Thanks!

[former_member196557]

Hi Colm,

You need to change the terminator strings to hex values: \0D\0A for a cr-lf terminator.

In production you also need to consider setting up a retry count and retry interval to automatically connect to the scale if it is disconnected from the network, or powered down. If there are no retries and the connection fails, the Agent Instance will have to be restarted to recover.

Is the scale set up to automatically issue messages based on weight changes, or do you have to send a command to the scale to send a weight? If command, how did you send through PCo15, did you use MII to write the message to the socket?

Regards, Steve

[Former Member]

Hi Steve,

Thanks for getting back to me.

I changed the terminator strings and send the command down but I keep getting the following value:

SEND|1|1|SEND_Result|0|SQL Data Type INTEGER

One of my colleagues was able to reverse engineer the .dll and from what he can see, this message is just a return code to say the message was sent successfully but there is no code in the agent to actually wait for the response from the scale which makes me feel like I'm using the wrong socket type.

To answer your question, the scale only sends the weight that is on the scale once it receives the SI<CR><LF> command.

Thanks,

Colm

[former_member196557]

HI Colm,

Sounds like you are sending the command via the MII PCoQuery FixedQueryMode with the SEND custom function for the socket agent. if this is the case, then the response has to be detected by the PCo Socket Agent Notification, which can then send the response to the destination. How have you configured the Socket Agent Instance Notification?

Regards, Steve

[former_member185280]

I wonder if you have to send the control characters (<CR><LF>) as hex in your send query? I don't think the scale is being triggered at all. In the past I have used Hercules as a test server or wireshark to see what is actually going over the wire. You should try and see if the message sent from your terminal matches what PCo is sending.

Regards,
Christian

[former_member196557]

I would expect that the printer command protocol would require some kind of terminator to identify the end of the command.  PCo Socket Agent Custom SEND function will transmit whatever is provide in the send payload; it does not strip any control characters out of the string.

Regards, Steve

[Former Member]

Hi Gents, I'm starting to think you're both correct. We have a command that should reset the value on the scale, when I send it from the TCP\IP Client, it sets the value to zero no problem, but when we send it from ECC through the PCo it has no effect. I know this isn't waiting for a response so for some reason the command isn't being picked up from the scale even though the log indicates it was sent successfully. I know it's not a network issue because the TCP\IP client is on the same box and I don't think it's a terminator issue as we've debugged the value inside the agent (we have a .NET developer that was able to do some magic) and the HEX value that were being sent down to the scale from the TCP\IP client and the PCo Agent were exactly the same.

I need to resolve this issue before I get back to you about the response but thanks again for your input!

Colm

[former_member185280]

Just to clarify I think it may not send <CR><LF> as actual carriage returns / line feeds I think it will just send '<CR><LF>' as a string. Some clients will automatically convert <LF> for you. I wasn't sure but I looked back at the printing project I did (simple example here ) and I had to put actual line feeds in the string to get it over the wire right for the printer to understand. The only caveat is that I was using an older versions of MII and an older version of PCo and the functionality had just been released. Anyway good luck and keep us informed of your progress.

Regards,
Christian