Goal of this guide is to have a working environment where IPC-CFX developments and manual tests can be made

Pre-Requisites#

• Have a local environment with MES/Connect IoT ready.
• Optional (but recommended): Project with support for IPC-CFX Feature Package/SMT Template

What is IPC-CFX ?#

IPC-CFX is an industry-developed open international standard forming the foundation/backbone of Factory of the Future applications. IPC-CFX is a plug-and-play solution that simplifies and standardizes machine-to-machine communication while also facilitating machine-to-business and business-to-machine applications. (from IPC.org .)

We use this driver on SMT/eletronics area to interface with several SMT machine types, mainly, but not limited, to inspection machines.

IPC-CFX consists of M2M (Machine to Machine) communication and brokered communication (through a message routing system - broker),

Our IPC-CFX IoT driver and IPC-CFX simulator support all communication methods.

EI integration#

On your MES local environment create:

• An automation protocol using IPCCFX driver,
• Empty driver definition using a Resource entity type (no properties, events or commands),
• An automation controller (with the default Setup workflow)
• An automation manager with a connected instance

Change OnEquipmentSetup task on Setup workflow with the following configurations:

That configuration allows both M2M and brokered communication (we will use both methods on this guide). In your project, you might have just brokered messages or just M2M.

First time boot#

When executing the manager, you should get the error: error: [AMQP] Unable to validate Publish channel '/queue/testQueue' at 'ExchangePublisher' 'amqp://127.0.0.1:5672/': One or more errors occurred. (No connection could be made because the target machine actively refused it) because no broker is installed yet.

Broker installation#

So, let’s install RabbitMQ as a broker. Please note: This is something that we will do here, as a development/test exercice but it’s not a task or responsability in our projects: to install or to configure an AMQP broker (we don’t actually recommend RabbitMQ or any other).

cd c:\Work\amqp git clone https://github.com/it-herz/docker-rabbitmq.git . docker build -t amqp . docker run -d --publish 1883:1883 --publish 4369:4369 --publish 5672:5672 --publish 15672:15672 amqp

With this you should have a running container with RabbitMQ. You now should have LISTENING ports on 5672 (RabbitMQ) and 15672 (RabbitMQAdmin) on your system.

c:\Work\amqp>netstat /an | findstr 5672 TCP 127.0.0.1:5672 0.0.0.0:0 LISTENING TCP 127.0.0.1:15672 0.0.0.0:0 LISTENING

When opening RabbitMQ Admin web interface http://127.0.0.1:15672 you can use “guest/guest” user/password.

If you run the manager now, the automation should be able to go in to communicating state (able to connect to the broker) and create automaticaly testQueue Queue.

Configure Broker#

Open RabbitMQAdmin web interface and create an exchange with the following properties:

{"name": "testExchange","vhost": "/","type": "fanout", "durable": true, "auto_delete": false, "internal": false, "arguments": {} }

Let’s create a binding from the Exchange to the newly created Queue:

Use IPC-CFX Simulator#

When the driver is in communicating status, we should be able to use IPC-CFX Simulator to send test messages and check automation logs.

Sending message to the broker#

For first test, we can send a CFX.ResourcePerformance.StationStateChanged with some test content { "OldState": 2200, "OldStateDuration": "00:01:25", "NewState": 1100, "RelatedFault": null } to the broker exchange. Since we have created a bind from the testExchange to our testQueue we should receive it on our ConnectIoT automation. CFX.Heartbeat are being sent whenever IPC-CFX Simulator is running.

Notice the log from automation: debug: << [0e310c9c-5c66-4f88-886a-fe9abc19d759] Received Event: of type 'CFX.Heartbeat' from 'keysight.i3070.i30704CE9310MC8.MY59250157.L1' occurred at '2023-09-21T11:27:56.9493357+01:00' Since we haven’t registered any logic for this event, it is being ignored. debug: << [c31dce12-5cf7-444e-9349-44ad458fd412] Ignoring Handle Request not Registered by Controller: type 'CFX.ResourcePerformance.StationStateChanged' occurred at '2023-09-21T11:28:03.3442859+01:00'

Since we don’t registered any logic for this event, is being ignored for now.

Sending messages directly to ConnectIoT endpoint#

Let’s try to send a M2M message CFX.InformationSystem.UnitValidation.ValidateUnitsRequest using the IPC-CFX Simulator:

{ "Validations": [ "UnitRouteValidation", "UnitStatusValidation" ], "PrimaryIdentifier": "CARRIER2342", "Units": [ { "UnitIdentifier": "CARRIER5566", "PositionNumber": 1, "PositionName": "CIRCUIT1", "X": 50.45, "Y": 80.66, "Rotation": 0.0, "FlipX": false, "FlipY": false } ] }

Again, we have not registered this request on controller workflows, so no valid answer is returned. debug: << [bfa55cb9-7048-4a44-8228-70ba5e7aae43] request: [REQUEST-901722b8-b3e7-42aa-a3b6-3f85c824146f] Ignoring Handle Request not Registered by Controller: type 'CFX.InformationSystem.UnitValidation.ValidateUnitsRequest' occurred at '2023-09-21T11:45:31.2527854+01:00'

Using COMMON IPC-CFX Feature Package#

We can start from scratch, but, we have already a full featured SMT implementation, using IPCCFX, available. Well.. there are always features missing. See “WIP” section. It’s outside the scope of this guide to show how to import a Feature Package or Product SMT Template onto your project. Please check the links on extra reference documentation (hint: Equipment Integration on DS SMT Template, slide #4). Please note that this will be ported onto Product SMT Template repository in the future (so please check that repository also).

After having this imported on your project, you can explore features and fine tune to the actual tests/developments needed.

Current developped logic supports:

• Station State Change
• TrackIn & TrackOut materials
• Post to Material Defects and Post to DC on UnitsTested/Inspected
• Material Interlocking

Further testing#

To add support to our logic to specific messages we use connect-iot-controller-engine-ipccfx-tasks tasks package. This allows adding support to any IPCCFX (other than the ones already preconfigured) by specifying Message Full Name and Inputs/Outputs on Cfx Task.

Now, on execution, this controller workflow will register support for these messages on driver: info: Registering custom event 'CFX.Production.UnitsArrived_0lydj8iruxch', for topic 'CFX.Production.UnitsArrived', associated with '5' properties info: Registered event 'CFX.Production.UnitsArrived' with success!

So when sending message on IPC-CFX simulator:

We should receive and handle it on controller: info: [5d3b3364|workflow_3076|task_4039|onCfxEvent] Received a 'CFX.Production.UnitsArrived' event from 'keysight.i3070.i30704CE9310MC8.MY59250157.L1'. info: [5d3b3364|workflow_3076|task_4039|onCfxEvent] Successfully updated task's outputs after received event 'CFX.Production.UnitsArrived' from 'keysight.i3070.i30704CE9310MC8.MY59250157.L1'. info: [5d3b3364|workflow_3076|task_4424|logMessage] {"messageId":"ffe7c697-4e14-4e6a-ba21-b0f83946a789","sourceId":"keysight.i3070.i30704CE9310MC8.MY59250157.L1","eventId":"CFX.Production.UnitsArrived","requestId":null,"occurrenceTimeStamp":"2023-09-22T08:59:12.543Z","emitTimeStamp":"2023-09-22T08:59:12.547Z","values":{"Lane":1,"PrimaryIdentifier":"123456789","UnitCount":1,"Units":[{"UnitIdentifier":"1234567890A","PositionNumber":1,"PositionName":"CIRCUIT1","X":0,"Y":0,"Rotation":0,"FlipX":false,"FlipY":false,"$id":"5"}],"$id":"4"},"$id":"3"}

WIP#

Some enhancements are being developed:

• UnitsProcessed for Reflow Ovens/Selective Soldering/Reflow Profiling Devices) (Update: already implemented)
• Using TransactionID as context key

Extra Resources#

• IPCCFX Simulator
• IPCCFX Bootstrap
• Equipment Integration on DS SMT Template

Author#

Hello my name is Nuno Nunes#

I am an IoT Lead for the SMT area You can visit me at LinkedIn

Skills: Connect IoT