Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kevin Olotu
    @kolotu
    That sounds interesting - that would be a good use case for the Vorto Repository to embed it in this greater architecture. It would definitely be abstract Thing Descriptions, as Vorto does not know specific device properties like Thing ID and endpoint addresses.
    How can we/you get in touch with Sebastian to participate in that effort?
    Kai Hudalla
    @sophokles73
    @kolotu I can introduce you to Sebastian by mail so you two can start discussing. WDYT?
    Kevin Olotu
    @kolotu
    @sophokles73 that would be perfect - thanks!
    Julian
    @JulianFeinauer
    @sophokles73 that's a very good idea... I'm so angry that I missed the Siemens talk
    Kevin Olotu
    @kolotu
    Hi everyone,
    Tomorrow Tuesday 17 March 2020 between 8AM-11AM CET we will perform maintenance works and a deployment on the main Vorto Repository https://vorto.eclipse.org. The repository will be inaccessible during that timeframe.
    Sorry for any inconvenience.
    Kevin Olotu
    @kolotu
    Maintenance will take longer than expected. ETA is now 2PM CET
    Kevin Olotu
    @kolotu

    We are facing some issues in the Vorto Repository. Some users might not be able to save models at the moment. We are working to fix the issue, we expect to solve the issue on Monday.

    We will send an update here, once it is resolved. Sorry for any inconvenience.

    Julian
    @JulianFeinauer
    Can I support you somehow @kolotu?
    Kevin Olotu
    @kolotu
    @JulianFeinauer thanks - we just rolled out a fix, so it should work already. We are verifying that at the moment.
    Kevin Olotu
    @kolotu
    The issue is fixed - saving models should work normally again.
    Kevin Olotu
    @kolotu
    Would there be interest in introducing a datatype for HEX properties in Vortolang? I have tentatively created an issue for it eclipse/vorto#2384
    Julian
    @JulianFeinauer
    Interesting Idea… I like how avro handles „komplex“ Types with their notion of „logical types“ vs „physical types“ (primitives how we would call it in java)
    as HEX in the ned is just… number?
    Kevin Olotu
    @kolotu
    yes HEX is a representation of a number, but since we already have integer, byte, float, etc in vortolang, maybe it would be useful to also add a primitive type for hex numbers. WDYT?
    Julian
    @JulianFeinauer
    If its not too much work it could make sense. Hex makes it way easier to express bit-masks (which are at least widely used in IIoT)
    Julian
    @JulianFeinauer

    Another Question that I have. Currently Vorto allows us only to define the „capabilities“ or „properties“ of a device but we do not have a chance to define how a „gateway“ could access them (e.g. "read from address xyz“). So I see the need for

    • Either an extension of the Specification or
    • A second complementary file format which allows to define this mapping.

    This would help us to get rid of client side code generation in some (standardized) environments. This would especially make sense in areas like IIoT (usually always PLCs to address) or think of the Bosch DYI products which I guess, have often times similar hardware with a standardized Layout and API.
    WDYT @kolotu?

    Kevin Olotu
    @kolotu

    @JulianFeinauer if I understand your question correctly you are asking, how platform-specific information (i.e. which address the gateway needs to use) can be added to a functionblock?
    That's something that could be done with Functionblock mappings, I think. They can be used to add additional platform-specific information to a functionblock.
    Here is an example how that currently looks in Vorto:
    A Functionblock: https://vorto-dev.eclipse.org/#/details/com.kevin.official.test:VehicleGearFb:1.0.0
    and the corresponding mapping that adds platform-specific information: https://vorto-dev.eclipse.org/#/details/com.kevin.official.test:VehicleGearCANMapping:1.0.0

    To see the result you can use this API: GET https://vorto-dev.eclipse.org/api/v1/models/com.kevin.official.test.VehicleGearFb:1.0.0/content/CAN

    Does this fulfil that requirement or did I misread your question?

    Julian
    @JulianFeinauer
    Thanks @kolotu this looks exactly what I was missing... Let me play around with it... Why didnt I find it somewhere.. This is a killer feature
    Kevin Olotu
    @kolotu
    @JulianFeinauer you didn’t find it, because it’s almost not documented yet - unfortunately! We have an open task for that...
    Julian
    @JulianFeinauer
    Okay, then its not only me
    good
    hier ist das ja noch nicht ausreichend Dokumentiert, oder?
    Kevin Olotu
    @kolotu
    Yes exactly. On the development branch of that file is a short paragraph on Functionblock Mapping, but I think there should be a more thorough explanation and an example use case.
    Julian
    @JulianFeinauer
    yep
    In my PLC4X Use Case… this file should be totally sufficient, right?
    as it references the DB
    FB
    Kevin Olotu
    @kolotu
    I think it could be sufficient - we should just try and see whether it covers your use case entirely
    Julian
    @JulianFeinauer
    Basically the Worflow I see for IIoT / Automation is… One Party creates the „Vortofile“ (comes out of Construction usually). Then second party (PLC Programmers) does the mapping to sensors / PLC Adresses -> Mapping file. This file we then take to spin up the Monitoring
    Kevin Olotu
    @kolotu
    Yes that sounds like it fits the requirement.
    Julian
    @JulianFeinauer
    Do you have a Blog Post or something which describes the exact use case you have in mind with the VehicleGear Example files?
    Kevin Olotu
    @kolotu
    no that was just an example to show that feature. The idea behind the VehicleGear example was to add platform-specific hex values to each gear, without "hardcoding" them in the functionblock, to keep it platform-independent and reusable.
    Julian
    @JulianFeinauer
    I see
    in our case this could also be machine specific (as each machine can be programmed slightly different… for whatever reasons)
    Kevin Olotu
    @kolotu
    in that case you would need one mapping file per machine / implementation of the machine
    Julian
    @JulianFeinauer
    yep
    But one more question
    the mapping in theorie describes the value of the respectice property or just som „addidional“ information?
    Kevin Olotu
    @kolotu
    the mapping feature is generic, so you can do both with - it is up to you
    Julian
    @JulianFeinauer
    great
    has vorto already an API to work with?
    Kevin Olotu
    @kolotu
    an API to create those Mapping files programmatically?
    Julian
    @JulianFeinauer
    or to read em
    Kevin Olotu
    @kolotu
    mapping files are treated as models, so you can use the /api/v1/models APIs as you would for Functionblocks, InformationModels, ..
    Julian
    @JulianFeinauer
    ah, neat
    Kevin Olotu
    @kolotu
    btw here is the issue about documenting the functionblock mapping feature: eclipse/vorto#1535
    if you have any thoughts or ideas, you can leave a comment on the issue
    Julian
    @JulianFeinauer
    Yes.. if i find time soon I will tackle that during the process and send a PR
    Kevin Olotu
    @kolotu
    that would be awesome :)