We are moving! We are currently migrating our community to the new Bosch Connected Industry Online Portal. The community will be available latest in the new year again, until then it will be in read-only mode. Click here for more information.
03-30-2023 10:43 AM
I am developing an object for very specific welding device because of its ardware structure.
Communication with device is done using 2 pcs of slave bridge EL6695 modules. The problem is following:
Now I am not sure how to structure my object. I have some scenarios and i would like to know your opinion.
Solution 1
Create command handler for control of common functionality of device and 2 separate objects for both Axis.
Solution 2
Create independent objects. One for control of device itself and 2 other for separete control of Axes.
Do you have any experience with similar task?
Solved! Go to Solution.
03-31-2023 06:52 AM
There are some information missing for me to make a proper decision, so I'll assume the following: You want to use the NexeedAxis object to control the axes and the whole object should provide a single interface for your object users so that they can integrate it nicely into their stations. Reuse is a concern, or else why create an object for it...
With these requirements I would create a single command handler object with 2 NexeedAxis objects as internal elements. The common control and status signals and all logic and sequences related to them I'd try to put into the handler itself, but if that proves impractical because there's just too much to do there, maybe create a separate object for it (which has visibility "hidden", because it can't be used without the handler).
Then I would create 1 or maybe 2 separate peripherals for the EL6695 which provide "IMyDeviceChannel1" and "IMyDeviceChannel2" so that linking the terminals with my object is easy. All the internal signal allocation from the terminals to the axes and the general stuff is done object-/peripheral internally. This also requires a base object for the interfaces. Not sure if NexeedAxis can be used as an internal element like that or its parameter requirements somehow make this impossible/impractical, but it'd probably work.
With this solution, users of my object would only need to drag 1 object instance into their model tree to get the whole thing. Linking to IO requires only 2 parameters in total. When scanning the peripherals from the PLC, the correct peripheral type for the terminals has to be selected though, but a single page of documentation in your object can cover this entirely.
04-03-2023 01:49 PM
I am sorry but I did not metion the axis is not controlled by standard Axis object. It is very specific welding device so I have to create everything from scratch. I will try to explain it more detailed. I created image of the architecture.
The main problem is I have two EL6695 peripherals and they are not the same. One is used for control of the Device itself + control of Axis 1 and second is used for only for control of Axis 2.
My idea is to create:
WeldingDevice (ComamndHandler) that consists from Axis 1 and Axis 2. The reason for that is I need Axis 1 and Axis 2 controlled independently (independent commands), but they both are dependending on WeldingDevice state. For example none of the axis can be started if the welding device is not powered on or calibrated.
What I do not know is how to transfer the data from area "Device Control" of EL6695 to Command handler Welding device.
It is hard to explain it in the forum, but if you can, we can discuss it together in Teams.
04-05-2023 10:15 AM
You can add 2 interfaces to your peripheral.
One for the Axis and one for the device.
Over this two interfaces you can send your state from the peripheral to your booth units.
04-05-2023 10:52 AM
Yes this is the right way. In the meantime i consulted this with @Thorsten_Brach and he recommended the same thing to me.
I just started with programming and it seems it will work as I expected. Thanks to both of you guys.