How SVG Single Line Diagram

You keep going back to this despite:

The last quote from @amarks is the most verbose piece of info for what i'm trying to drive home.
I.e.
Devices should be their own objects; their own Views that should link to UDT instances. Period. Devices should never be included and animated within a single SVG presenting the entire P&ID, it's simply not maintainable or efficient. What about representing all of the other statuses of the devices like mode, running, alarms, speed, current, etc. etc.

1 Like

Sounds like its time to cook. Thanks.
Keep u guys posted how it turned out.

This is the main reason we moved away from single SVGs.

They can work great if you have something static - e.g. we have a single-SVG one-line for a specific inverter model, with lots of text and visibility binding to display metering values, power flows, switch positions, etc. - but the moment the underlying SVG needs to change it's a disaster.

Our new diagram utility which I described above (and which can live completely on the tag provider with string-encoded json injected by @pturmel's spreadsheet import tool) is so much more convenient that I intend to use it even for relatively static diagrams such as a specific device's one-line/wiring diagram.

2 Likes

This should hopefully be a non-issue with drawing tools in 8.3 :crossed_fingers:

This sounds interesting, but I don't see anything related in your earlier posts?

1 Like

Oh I guess I alluded to it but did not declare/describe it. Essentially an embedded library view that take json from document tags to build instances on a view canvas and a SVG background. It's still a work in progress.

One major enhancement would be a way to convert components in a coordinate view to items in a view canvas array and back. This would allow drag-and-drop embedded views to build a diagram, then convert to a view canvas, instead of today's painful workflow of hunting and pecking modifications within the view canvas instances. Convert embedded views to view canvas instances?

Hi lrose,
Cc All,

Could you explain alternative to using coordinate container.
Right now I have each P&ID devices as individual views, and I laid them out in XY coordinate. And it looks good.

What is the best way to finally render this on screen?
The diagram breaks when I set XY root to percent (wanting it to scale).
Does that mean, I am left to have this fixed size for any browser size?

Any way to make XY piping scale up and down without breaking apart?

I use SVGs for anything I want to have scale with the view size. The view box of the SVG will determine the rate it scales. This is particularly relevant with text. A good example of this is currently working its way through the approval process on the exchange. Of course, you can also use scalable units on text but you can't mix the text with SVGs because you can't control where the SVG will be rendered at all sizes.

You can embed the SVG on a view and embed that view on a screen.

I don't prefer using % mode on coordinate containers for P&ID screens. I have gotten them to work "ok" but it's much easier to get a reliable layout with a fixed layout and it lets you support more devices through scrolling on applications that were not designed to be mobile. Designing P&ID visualization for mobile takes a lot more work and I haven't found many customers that want to pay for that. They're usually happy to be able to scroll across the drawing in a project that was not designed for mobile.

I was going to proof this better but I'm being called for dinner so hopefully you understand what I'm saying.