OK, next, datamodel....
# umh-support
c
OK, next, datamodel....
j
Creating a new thread to keep it separated: > Wouldn't I want to add some basic data before adding a product; location, shift. For production use anyways. We have many customers with different locations. So a location would be configured in "assettable" AND assets would be added for that location? Why not locations that assets are tied to? A "locationstable" and the "assettable" has FK relationship to "locationstable"? For shift I see "type" 1 for shift and 0 for no shift. Is this to schedule downtime? > Would I use shift 0 for planned downtime and record it as State "Planning"? > I'd be interested to see an example of how UMH is being used in the real world. I'm going to be using it either way, but seeing it in action vs figuring it all out as I implement would be helpful. I currently can see that we will have to make a UI to accomodate some of the data collection from the shop floor users. What can be automated will be, but the use cases I'm seeing for our existing customer base would have to have some operator data collection for things like, starting this order on this asset running this part and so-on. > I'll be setting this up for production use at a customer that only has one building. They have printing presses that they want to track the speed and count. This should be pretty simple to do with UMH. I'll pilot sensor data into grafana for pilot. Eventually, I'd like to add order and product, but this will require a custom UI. We have a front-end developer that I can push that onto once I have a better idea of what we need to ingest.
To use the UMH datamodel, you only have to publish messages to the Unified Namespace. Everything else will be created in the database automatically. You only need to touch the database to configure the OEE calculation. See also our (not yet published) feature descriptions of Historian and Shopfloor KPIs: - https://feat-xxx-features-section.umh-docs-umh-app.pages.dev/docs/features/analytics/ - https://feat-xxx-features-section.umh-docs-umh-app.pages.dev/docs/features/historian/
We are still figuring out how to best explain the KPI stuff to people, so if you have any questions, feel free to ask. For the printing press, I'd do something like this: 1. Push all the process values / tags of the PLC to the Unified Namespace for the Historian feature 2. Now create a Node-RED flow that takes some of these tags and publishes /count messages. So every time you produced one additional piece, you send a count message for that asset. https://umh.docs.umh.app/docs/architecture/datamodel/messages/count/. One example flow can be found here: https://github.com/united-manufacturing-hub/community-repo/tree/main/Node-RED/flows/count-processing Another one here: https://github.com/united-manufacturing-hub/community-repo/tree/main/Node-RED/flows/optical-distance-sensor-for-conveyor-belt-item-counting 3. Once you have the count messages, you can create from there a logic basically saying "if there are count messages coming in, send a /state message. if no count message came in in the past seconds / minutes, then set the machine state to unknown stop (40000). Example: https://github.com/united-manufacturing-hub/community-repo/tree/main/Node-RED/flows/state 4. you could fine tune this logic by adding logiclike, if no counts are coming in AND a maintenance door is opened, set the machine state to maintenance. Example: https://github.com/united-manufacturing-hub/community-repo/tree/main/Node-RED/flows/inductive-sensor-door-switch-preventive-maintenance 5. finally, add a shift plan https://github.com/united-manufacturing-hub/community-repo/tree/main/Node-RED/flows/addShift
now you should be able to build a simple Grafana shopfloor KPI dashboard
From there on, you can add more and more information and the system will autoamtically detect a couple of states automatically, like changeovers (see https://feat-xxx-features-section.umh-docs-umh-app.pages.dev/docs/features/analytics/)
For operator input, we used Node-RED dashboards so far. I think @DanielH and @Onur Can KARAMAN - ASO did it like this as well. BUt as Daniel pointed out, they will be quite simple and will not allow authentication or authorization. in this article we have somewhere further below an example picture of such a Node-RED dashboard providing the option to enter stop reasons and it will show the produced pieces. https://learn.umh.app/blog/node-red-in-industrial-iot-a-growing-standard/
o
Hello @Jermuk We made an ultra-simple application. Of course, it was actually designed by the operators. (For Creating Production Orders, Adding Products etc.) I am doing this with a software developer friend. He name is Emrah NALCI. Of course, we develop it whenever we find time from work. Seems like it will take a while. I can take pictures of the first images from the production workshop and share them.
j
that would be great! we are also almost ready to release the date and time for our community meeting.
o
@Jermuk I'm looking forward 🙂
2 Views