“Weak currents”

As I was reading Justin’s case study reminded me just how important it is for audio-visual consultants to be involved in a project from the word go. When this is not case things can get very interesting. Here’s a story from my life as a designer.

A rich benefactor has a vision – to build a really wonderful concert hall. He gets together a bunch of wise men and women to realise his dream. Architects, acousticians, structural engineers, electrical engineers and HVAC specialists.

But wait says the patron, let’s also put on operas, and show films, and theatre, and let’s make some money by holding conferences. All great ideas! The design team look worried at first, but soon they are rubbing their hands and looking forward to putting their grandchildren through college on the back of this project…

As the last concrete is poured, the electrical engineer mutters something about “weak currents”. Sounds like a minor detail. But indeed,  there is some infrastructure needed that no-one has thought about. Those “weak currents” that carry the audio, video, lighting control, comms in fact everything needed to make the building fulfill its proposed function. About time isn’t it to bring in the “weak currents” guys?

Nothing like the last minute for the audio-visual designer. And somehow he’s expected to equip the building with state-of-the-art systems when no-one else on the team has given a moment’s thought to providing space for equipment, control rooms, cable paths, places to mount lights etc. etc.

A familiar scenario? Let’s look at the impact of this awful decision.

weak currentsControl rooms with no access to backstage areas. So a shabby-looking technician has to elbow his way through the foyer crammed with well-dressed paying audience. Not good.

What about interpreter booths for those conferences? We’ll squeeze them in somewhere. Aren’t there standards for these?

To get light onto the stage you need at least some holes in the ceiling to poke the luminaire through. Did the acoustician think about that? Now we’re in a bargaining exercise for each and every lighting position.

Sight-lines? Not good for films if you can’t see the screen. Key-stoning? What’s that? Big projectors are kind of bulky and produce quite a bit of heat. Any air-con in those minuscule control rooms? No, let the technicians have a free sauna.

Who needs cable paths? Isn’t everything wireless these days? Anyone think that some signals don’t travel well so you can’t route them all the way around the building? That’s assuming that a path can be found. In an earthquake zone structural engineering is a serious business. Each hole needs the building to be re-calculated. Not to mention the cost of drilling through 1 metre thick reinforced concrete.

All in all a recipe for a massive budget overrun and a permanently unsatisfactory result. So it’s good to see some projects like Justin’s getting it right.

When you’re building a new venue of any kind get the “weak currents” people on board right away. They’ll save your project.

Beyond pretty pictures

Computer-aided design when it first appeared swept away a mass of drawing boards, scale rulers, compasses, protractors and the highly trained draughtsmen who used them. Gone were the traces of Tippex and eraser marks. CAD became synonymous with neat plotted scale drawings. But I still come back to the question “how much is the computer really aiding me as a designer?”.

In the ’90’s I began work at a company and was momentarily impressed when I saw them using a spreadsheet program for their quotations. Until I realised that the secretary was adding up the numbers on a pocket calculator and typing them in. Nobody there knew that the computer could do sums! For them it was just an infinitely erasable piece of paper. And in a way general-purpose CAD software still seems to be struggling to leave that phase.

For sure we have 3D now and there are many special purpose add-ons to CAD to help with a multitude of design tasks, but very basic real-world concepts are not built in to the software at a deep level.

For example in my world of audio-visual technology we work with connectivity. Equipment joined by cables. The concept of a connection, ubiquitous in our world today, is a perfect instance of what’s still missing from most CAD software.

Too often by the time an add-on product has matured the problem has moved on. What we really need is a fundamental shift.

ideas for people

Design is about creating things that people will use. There’s a lot more involved than just the dimensions of objects. It’s about making things that work. Computer-aided design should help us to try ideas out, see things working, and catch problems before they arise in reality.

Yet even now most of the design process – the actual thinking behind it, is more in the designer’s head than in the CAD model. And the key word here is model. CAD drawings are still a very limited model of the systems they represent. To broaden and deepen the way in which designers work with CAD the software itself needs to evolve into a system modelling tool.

“A picture is worth a thousand words”?

Not in the world of CAD it seems. Just look at it – our drawings are still full of text: text to explain what the lines actually mean. Not exactly visual communication nor even helpful to the human mind. For sure text is needed sometimes but what about colour, texture and shape? Text belongs to the logical one-thing-at-a-time left brain. But it’s that massive integrative power of the visual right brain that lets us understand things at a glance and see the big picture. This is the power of a good drawing.

A few years ago I found myself writing code to grab desk ID texts from office drawings and integrate these into smart desk objects so we could model who was sitting where and how well the design fitted actual human needs. This “non-drawing data” ought to be an integral part the model, not something  sprayed on afterwards.

In the construction industry Building Information Modelling (BIM) is finally moving in the right direction. Now at last we can ask the question of a drawing “how many windows are there in this room?” and get a sensible answer. How long has it taken for the CAD system to “know” what a room is and what “in a room” means?

modelling not drawing

Highlighting the issues is the easy part. Knowing what to do about them is another thing altogether. I’m not short of ideas.

We need to move away from drawing primitives like lines, rectangles, arcs and text, and start drawing objects. Yes, these will contain all of the above but they will be functional models of the real-world objects they represent. Their properties won’t be limited to drawing attributes. They will “know” where they are in relation to other objects. Visual properties e.g. size, shape, color etc. will be able to be linked to other properties of other objects even bi-directionally. Imagine being able to drag the height of a rectangle and change the temperature in your model. Or being able to visualise that as a heat map?

We need a class hierarchy of objects that inherit properties from their parent classes. And we need to be able to link class properties with properties of specific objects or external data sources to visualise the effect of changes and engage that right brain.

Objects should be able to consume resources from other objects. So often design problems revolve around figuring out how much or how many we need. Resource usage gives us that in a nutshell.

questions, questions…

Creating a model lets us ask questions. Once our right brain has seen and liked what we’ve done, we still need to analyse the design and present the information in a step-by-step manner for implementation. So now we need to treat the drawing as a database.

There’s no need to re-invent the wheel here. SQL should be built-in to all CAD programs. Of course we can add lot’s of nice UI to help users build queries, but that’s the power we need underneath.

How to express the answers? Visually of course! Queries should be able to drive the drawing and give us pictures as well good old traditional tables of text and figures.

complexity and where to put it

There seems to be a law of conservation of complexity. You can move it about, hide it in corners but you can’t get rid of it. And I realise that what I’m proposing is complex. But so is the real world we are trying to model. So the question is where do we put the complexity?

For the purpose of designing a model it’s nice to deal directly with objects and their properties and relations. This keeps complexity distributed over the model and local to the objects.

But any programmer will tell you this is hell to debug. Dependencies all over the place can lead to hours of work trying to track down what’s happening. So we need to find the sweet spot. And I think it’s this:

Although you create and edit locally to objects the actual “code” that executes the model should be stored and run from a central place so you can step through and see what’s happening. This also has advantages for delivery. Quite often you want to give a client a snapshot of how your model looks but not the model itself. So having the intelligence outside is handy.

signing off

As the developer of an add-on to Vectorworks, I often feel with connectCAD that I’m struggling to add features that should really be part of the platform. And Vectorworks is one of the better platforms. It already has a lot of advanced features that were in it from the beginning. But linkage and connections are still a tough call.

Expressing  frustrations does one good of course. But I also hope that we can move towards a new era of design software where the designer spends less time trying to guess the outcome of  decisions and more time in a genuine interaction with a model.

What is the future?

Just to get away from CAD issues for once… well almost.

The world of broadcast television is headed for a disruption similar to what Skype did to telephony. And it’s all about IP. For years now broadcast technology has been using more and more standard IT infrastructure. As computers have got faster and faster software has become capable of doing the jobs that once needed custom hardware. So now where are we at?

Let’s look at what a TV station does.

We take in content as streams and media files, adjust them to our standards, add branding etc. and create… a stream.

Until now this process involved cumbersome conversions of incoming media into broadcast signal formats (e.g. SDI) to do all the processing and monitoring etc. But we are seeing software products emerging that can take the incoming content as is, and produce a branded stream. That renders existing playout systems obsolete.

So what do you need to do this? Well in terms of hardware basically nothing. You can rent storage and processing power from cloud providers and deliver your stream anywhere on planet Earth. Removing a whole swathe of capital investment from the equation!

For broadcast engineers this means a gradual phasing out of in-house plant. Systems design gets a whole new focus. The hardware element moves out to the design of bulk IT plant, and the workflow aspect becomes an exercise in visualising the flow of content.

Broadcast is not the only area that will be swept up in this revolution. Audio-visual is fast moving towards IP-based systems. Again distribution and routing of AV becomes the province of IP networks. Audio is already there with systems like Dante. Video is coming on fast.

Systems design is not dead. You won’t be able to just hook everything up to a network and hope it will work faultlessly, but the design process will fork into  two-levels: function and implementation. The design of hardware will focus on providing “pipework” of the right size for the anticipated traffic. And function will be abstracted into the configuration of the network. Since the line between configuration and status is a rather blurred we could well be seeing diagrams linked live to the systems they depict and providing control, configuration and status in one go.

All a far cry from the world of patch panels.

 

Be your own artist with schematics

Schematic diagrams can be  just a common-looking plan.. or you can choose to add a personal touch and express the artist in you, by making stylish diagrams with colors and images. So you can illustrate your personal style while making the whole project more amusing for installers and other collaborators.

connectCAD lets you customise all design options and give your drawings a unique look. Just create a custom template and please all the people all of the time!

Here’s some examples of stylish schematics using connectCAD:

Schematic Diagrams with connectCAD and Vectorworks


Schematic Diagrams with connectCAD and Vectorworks


Schematic Diagrams with connectCAD and Vectorworks


Schematic Diagrams with connectCAD and Vectorworks


Schematic Diagrams with connectCAD and Vectorworks

 

Options are endless, and creativity is the only limitation. After all, it’s your design your style.

Bridging the gap between schematics and reality

Over the last year I’ve been working to devise a convenient way to design cable paths. What I mean is to be able to show locations of equipment on architectural plans, and the paths of conduits, trunking or cable tray that will carry the cables that inter-connect the equipment.

It’s a problem that’s nagged me for many years. At one point in my life I was involved in designing broadcast TV signal distribution for a large international sporting event. As a design experience it was like wrestling jelly.

Real world cable path design is not a stately progression from schematic to details of trays and conduits . There are big rocks in the road. When you get to the site you’ll find problems like the aircon people have filled your hole in the concrete with their duct. And that’s not all – you get caned for over-capacity and vilified if the pipes are too narrow. It’s a no-win situation.

As a broadcast or audio-visual designer, the detail of cable-carriers are not your job- electricians do that. BUT they need a specification to work from. They need to know where the ends of the cables have to be, how many cables of what type go from where to where, and maximum lengths and bends radius limitations. So they need a plan like this.

Cable Path Specification
Cable path specification

Your boss will also be nagging you for an estimate of how much cable long before the electrical contractor can give you actual path lengths. So… in fact you do have make your own design of cable paths. Only by modelling in 3D can you really get a proper estimate of the lengths.

3D Cable Path Model
3D Cable Path Model

But, you definitely don’t want to show that to an electrician. In the construction industry people are trained to seek any opportunity to avoid responsibility and throw blame on others. So if you hand your electrical guy a plan like the one above, regardless of practicality he’ll go put the conduits exactly where you drew them and produce your drawing if anyone complains.

So our problem becomes one of making fast convenient tools to do a fairly detailed design for estimation purposes but be able to present it as a specification drawing with paths shown as  arcs, plus a “riser diagram” which just shows connectivity.

Riser diagram
Riser diagram

We also have the problem of finding the cable tray fills. If we have a schematic of our system or a cable list then we know the theoretical inter-connections. So it then becomes a case of assigning physical paths to these. In many cases (but not all) there will be only one path. Analysing cable tray networks into discrete A->B paths is not altogether simple since there may be loops in the topology.

As you can see from the drawings above, we’ve been making progress. However…

In to all this soup came Revit. The reality is that more and more projects are beginning life as a Revit model. That raises many questions.

We wanted to bring cable path planning into connectCAD 2016 but our feeling is that we need a closer look at where our data is coming from. The days of 2D plans and elevations are numbered. Perhaps the question is a different one? How can we depict cable paths in Revit and extract their topology, connectivity and lengths?

Has you’re life as a designer brought you in contact with this? Comment below. It’s good to talk 🙂

Happy new year! Stay connected

Coming up in connectCAD 2016

Coming up in connectCAD 2016:
Cable Paths extend beyond schematics to the physical world:where the cables go in a building,what are the specific locations of wallboxes/cable drop points & the paths between them.You’ll be able to make your own customised Devise Placement Tools that can insert into circuits, eg, if you’re designing RF distribution systems you can create your own handy tools for splitters / taps etc. using duplicates of Insert Device each set up to place a custom device symbol..

Read more

Knowing where to tap…

from Mark Buckton – absolutely brilliant!

A Giant Ship Engine Failed.
The Ship’s Owners Tried One Expert After Another, But None Of Them Could Figure Out How To Fix The Engine.

Then They Brought In An Old Man Who Had Been Fixing Ships
Since He Was A Young Man.
He Carried A Large Bag Of Tools With Him, And When He Arrived,
He Immediately Went To Work. He Inspected The Engine Very Carefully,
Top To Bottom.

Two Of The Ship’s Owners Were There, Watching This Man,
Hoping He Would Know What To Do.
After Looking Things Over, The Old Man Reached Into His Bag And
Pulled Out A Small Hammer. He Gently Tapped Something.
Instantly, The Engine Lurched Into Life. He Carefully Put His Hammer Away.
The Engine Was Fixed!

A Week Later, The Owners Received A Bill From The Old Man For Ten
Thousand Dollars.

“What?!” The Owners Exclaimed. “He Hardly Did Anything!”
So They Wrote The Old Man A Note Saying, “Please Send Us An Itemized Bill.”

The Man Sent A Bill That Read:
=====================
Tapping With A Hammer……. …….. …….. $ 2.00
Knowing Where To Tap……… …….. ……… $ 9,998.00
====================================

Labelling conventions and human nature

Labelling when you think about it is what keeps the world organised. And in our crazy little world with all its wires and connectors without some kind of labelling system we would soon lose our way.

The completely arbitrary nature of labelling makes it a special challenge for a CAD developer. We’d love to provide you with super-automated tools for this, but no matter what road we take someone will tell us it’s wrong, or agree with us but not be willing to change their habits.

Take patch panels for example. Some people label them like this:

A 01 02 03 04 … 21 22 23 24
B 01 02 03 04 … 21 22 23 24

C 01 02 03 04 … 21 22 23 24
D 01 02 03 04 … 21 22 23 24

So the top row of a panel has one letter, the bottom row has the next letter and the patch points are numbered across.

Others like it this way: each panel gets a letter to designate it and the patch points are numbered left-to-right then top-to-bottom.

A 01 02 03 04 … 21 22 23 24
A 25 26 27 28 … 45 46 47 48

B 01 02 03 04 … 21 22 23 24
B 25 26 27 28 … 45 46 47 48

The snag here is if there aren’t enough connectors you can’t easily change the patch panel size in mid-design. A good workaround for this is to label panels as though they were 50-way regardless of actual size:

A 01 02 03 04 … 21 22 23 24 (25) (26)
A 51 52 53 54 … 71 72 73 74 (75) (76)

That let’s you easily extend your panels to 26-way or 32-way without having to re-work everything, and makes efficient use of the available namespace. That’s quite smart. And if I had to pick one this would probably be it.

Most people agree you should skip the letters I and O because they can be confused with the numbers 1 and 0. But guess what? there are some folks in the world who didn’t do that and now they’re stuck with the system they have.

Others like to use numbers throughout and add a prefix to show if it’s a video or audio patch panel like this:

V01 01 02 03 04 … 21 22 23 24
V02 01 02 03 04 … 21 22 23 24

V03 01 02 03 04 … 21 22 23 24
V04 01 02 03 04 … 21 22 23 24

And many variations on these themes exist.

And then we move on to location-based naming. Great idea but very hard on the designer. Think about it… In order to know what equipment you have to mount in racks, you will probably have to finish the schematic designs first, right? So you do the rack layout and then go back and label your patch panels! and guess what happens if you have to modify the schematic???

By now you’re probably beginning to see how the simple business of writing a patch panel tool becomes a nightmare of complexity.

The problem with labelling conventions is that people are very attached to their own way of doing things. And with some justification because who wants to go back and re-label everything?

But there’s another psychological dimension to it. The more arbitrary and fundamentally insignificant the decision the more emotionally invested people become in it. A well-known cognitive bias known as “bike-shedding” or Parkinsons Law of Triviality. In labelling there is no absolute truth so you can fight to the death over it and NEVER, NEVER BE WRONG!

The lost opportunities of data validation

Conventional programming wisdom says you should always check any data input from the user and exclude anything that your code cannot cope with. [“User” … a strangely demeaning term for a person whom you are trying help. We need a new more respectful word for the people who are left struggling with the results of our coding. ]

Anyway, the normal practice with data validation is to only pass on whatever gets through the filters for further processing. All well and good. But what about the input you reject?

99% of the time when input is rejected the only action taken is to present the “user” with an suitably arrogant message.

"ERROR: We can only accept your information if you kneel with your knees exactly 10cm apart in front the great computer and bow deeply".

But what we as programmers routinely throw away contains vital nuggets of information – the cases we did not properly consider. Take my address for example. I live in a village where there are no road names or house numbers. What happens when I try to order something online?

I come up against the preconceptions of the programmer who designed the address form. House number and street name are required fields into which I’m  forced to enter rubbish just in order to get my order accepted.

The fact that the program is expecting a house number and street name in each case is a design flaw.  That information should be captured and fed back to the programmer.

the penny dropped!

Blogs are the new confessional, a place to cleanse the soul by publicly admitting  failures. My question to the powers that run the universe is:

“why has this taken me so long to think of ?”.

Problem: connectCAD likes objects to be on the grid

Solution: laboriously click on each object and drag it back onto the grid

or

About time too. How come I didn’t write this simple and useful command all these years? Still kicking myself.

Thanks to Edward Kitchingman for finally jogging my mind.