It's not just one dev (you) that needs to know though, it's all devs that work on the system, and it's assuming they remember every time. And to fix up that mess, even knowing the issue is there, is a nightmare. You have to copy and edit the raw JSON, manually updating the propsConfig array indices; for complex pipework, that's insane. Imagine you delete just one pipe in the middle and add 10 more in different z-order positions. To fix up the animations is near impossible unless you've noted down every single relative index move 
1 Like
I hear you and I'll keep that feedback in mind when advocating for priority of piping improvements over Drawing Editor improvements, and an increase in resources so that we can do both in a timely manner.
6 Likes
In the grand scheme of things I still count myself happy I don't have to work with [insert other scada package name] and can concentrate solely on Ignition.
It's a pain sure, somehow we carry on!
To be honest, working in Vision, I would rather use labels than paths for simple horizontal and vertical lines or 90 degree angles, but one thing IA definitely got right was the numeric text fields that appear when the developer selects an individual point on a path. Relying on snap to grid and eyeballing level with mouse drag doesn't work.
Being able to see and set the precise x and y coordinate for a given point makes it super easy to ensure the lines are perfectly square and level.
We gave up on piping after dealing with frustrations the few times I tried to play with it, but didn't want the hassle of bindings within our SVGs. @pturmel gave us the great idea to overlay a View Canvas on top of a SVG in a coordinate container, with both having the same dimensions. Highly recommend this route if anyone wants something where they can draw lines simply within a SVG, but use embedded views for components and interaction on top of them.
1 Like
The View Canvas seems like a slick idea. Do you create the instances manually or have you found a convenient way to add automatically?
We use view canvases all over the place now that I realize how powerful they are, but most of the time their instances are automated. But, in the case of our diagram package, it was difficult to manually edit instances. Without digging into the instances and looking at the viewPath and params passed like tagPath, it's tough to determine what you want to edit.
So, we commissioned a utility which allows us drag and drop embedded views, then it parses the view json and converts those embedded views into view canvas instances. It's quite slick, to the point where I've considered ditching the SVG backdrop altogether to rely solely on embeds from a view canvas.
The way we store our view canvas instances is a little non-traditional and does not allow bindings, but we have it parse tagPath params for the view and the embedded view and come up with some %(tokens)s that are interpreted in our deployment scripting.
2 Likes
So are you just using an SVG for piping with your components in the view canvas? Or are you doing your "piping" inside the view canvas? Or am I completely misunderstanding what you're using the view canvas for?
I've made 3 versions of piping tools that I use.
- just CSS that I can swap out with animations applied to labels for pipe colors
- the same but inside a template in a flex container so I can animate the basis on pipe corners to make them appear conditionally (easier to manage when the corners aren't tiny labels)
- All CSS with corners flown in as pseudo elements using animations on the CSS
All 3 work. My preference is on #2 because it's really easy to use and maintain. #3 is a pain to maintain when your pipe diameter changes and it has to be static per set of pipes in the model (it's a mess). I messed around with it but decided not to use it on a live system because I feel like it's less supportable.
#2 is really nice and easy to use. Performance so far has been great even on fairly complicated process screens.
Though.. don't get me started on if I want to delete a pipe and then manually move all of my pipe bindings 'up one'
. They all stay linked to n pipe rather than auto updating to n-1 as the pipe is removed.
Sorry for a brief hijack, but this right here, in general, is for me one of the biggest issues with designing in perspective. It happens in so many places, not just piping.
Almost any list of things where you have direct bindings on an element in that list, the actions of inserting/removing items are not handled to update the indexing of the bindings. Infuriating. 
</rant>
You can all go back to talking about piping now.
2 Likes
This was meant to be fixed the the ... late 20s early 30s? versions of 8.1.x I think, but it's still there for piping for some reason 
I remember the release note, I got excited, I updated, still broken.
I'm not really sure what you mean by using the View Canvas. (I haven't used it myself, but...) Isn't the View Canvas essentially just a limited coordinate container that can only display embedded views defined in its array prop? You can fairly easily create the JSON for adding device symbols (EVs) to a coordinate container, and you can obviously also add your pipework as an SVG into a coordinate container, so I'm not sure I follow the reasoning here to use a VIew Canvas instead?
I don't know, it seems to work for me...
HOwever, for pipes props.pipes, this fails...
IDK maybe the true CSS wizards could do everything I do but without embedded views. But here are some examples of things we embed on our diagrams: Device icons with self-deploying labels and overlays like alarm icons, larger composites/cards like an entire power meter, etc. The most important reason for us to do what we're doing is that literally all customization/configuration for a particular deployment of our product lives outside of the Ignition project stack, such that we can have a common Ignition project stack deployed to countless unique sites which then self-configures in real-time based on assets outside the Ignition project stack. It's not magic but I'm also not quick to explain that last piece of the puzzle.
1 Like
Ok, that definitely makes sense then if you're dynamically creating the content on the fly. I was thinking they were more of a fixed screen and you were just using the view canvas to help automate the creation of them. Seems like an interesting project!
I stand corrected. I just fired up a new container with 8.1.44 and the controls I was still seeing it on appear to all be fine now. Time to update everything 
Hopefully pipes gets the treatment before 8.3
I feel triggered
1 Like
I feel like your approach is probably more supportable than a more complicated approach using pseudo elements or something along those lines. Lower technical debt and less phone calls while on vacation, etc.
I typically prefer a simple approach.