search

Open-Mobile-Robotics / open-process-library

Open Process Library
MIT License
16 stars 2 forks source link

Make a Figma design for the valve faceplate #3

Open aott33 opened 1 month ago

aott33 commented 1 month ago

Ongoing process that started in the SASE Slack channel. Feel free to add details from the Slack Thread here.

kjetilnordby commented 1 month ago

Thank you, this is very useful. We are thinking of doing a trial where we transfer the screen to OpenBridge guideline. Would that be useful? We can use this to make some adjustments to our current IAS guideline.

kjetilnordby commented 1 month ago

our system support different pipe types. So, it is possible to switch between pipes with and without medium in the design.

andy-gxpaasio commented 1 month ago

Thank you, this is very useful. We are thinking of doing a trial where we transfer the screen to OpenBridge guideline. Would that be useful? We can use this to make some adjustments to our current IAS guideline.

How about @zantiu (Davy) and I put together a sketch of a typical process screen with some typical components. Will probably be a tank with some valves and pumps. Maybe we use that as a base for demonstration going forward and slowly add and tweak.

andy-gxpaasio commented 1 month ago

nd without medium in the d

This would be ideal. I have a hard rule about no pipe animations but I know a lot of people like them.

zantiu commented 1 month ago

Me??

zantiu commented 1 month ago

Ok how about some ingredient tanks, blending tanks and buffer tanks? 3-2-3? Should provide some basic density without making it very complex.

andy-gxpaasio commented 1 month ago

Created #15 to track this work.

Flowject commented 1 month ago

Lots of activity here the past few days! My 2 cents:

I REALLY like what OpenBridge is doing. Close enough to what industry people are used to still, but applying design best practices and drawing inspiration from the IT world. The gap in the valve, the spinner for opening/closing, I love it.

@kjetilnordby would be the way to go to implement this in a system that doesn't support JavaScript? In my case, and probably one of the first for this project too, IA Ignition. Can I find the svg and css files (no sass/scss support either) somewehere separately?

Good example screen there from @andy-gxpaasio on what's done today in the industry for a level 3 screen.

I agree with the transparent (same as background) fill color for manual valves being industry standard. Although debatable if it even belongs on a SCADA screen if there's no feedback captured.

As for showing the S for solenoid, doesn't matter from an operational point of view so doesn't belong on a level 3 screen in my opinion. Add it only on a L4 screen/popup for maintenance.

I'm also a big fan of spark lines as well as radar charts. Nothing worse to have on the screen than a bunch of numbers without context.

Flow orientation I say left-to-right and top-to-bottom generally, regardless of what the actual P&ID looks like. Keep it simple and easy to read. And navigation buttons (arrows) on the pipes to move to the page continuing the flow.

Agree with @zantiu and @andy-gxpaasio on pushing back on pipe coloring generally. Although with proper system behind it, it should work. If you're tracking it anyway for example because of contamination and cleaning states, you have the info. A graph DB sounds like the way to solve this, but so far what I've seen is PLC hell.

PEA visualisation is an interesting point. Similar to ISA88 EM, Unit and phase visualisations for level 2 screens.

Lot of these things seem of scope this CM/valve module though, but to keep in mind for later.

andy-gxpaasio commented 1 month ago

@kjetilnordby would be the way to go to implement this in a system that doesn't support JavaScript? In my case, and probably one of the first for this project too, IA Ignition. Can I find the svg and css files (no sass/scss support either) somewehere separately?

I think a good general approach is to let the OpenBridge team built the beautiful graphics with named attributes and functionality. Then when it's time to port we have a reference implementation to emulate. Some modern platforms might allow the SVG import and make use of the features. Others might require a from scratch build but at least we have a functional spec to go off of in the form of the reference implementation. On some platforms you might not be able to match all the features. At which point if it's a major platform (i.e Wonderware, Rockwell, Siemens) I think we loop back to our reference design and debate if the particular feature is too complex for the general use case. I think we are going to iterate many many times to get this right in the early days.

durinwinter commented 1 month ago

@Flowject if we use this method I can codegen the object into other places. I intend to make a tool that will take the defined "golden object" and codegen it into the various systems.