Jump to content

Search the Community

Showing results for tags 'irrigation'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements
    • Announcements
    • News You Need
    • Job Board
  • Feedback
    • Wishlist - Feature and Content Requests
    • Known Issues
    • Wishes Granted / Issues Resolved
  • General
    • Troubleshooting
    • General Discussion
    • Architecture
    • Site Design
    • Entertainment
    • Vision and Previsualization
    • Braceworks
    • Rendering
    • Workflows
    • Buying and Selling Vectorworks Licenses
    • Hardware
  • Customization
    • Marionette
    • Vectorscript
    • Python Scripting
    • SDK
    • 3rd Party Services, Products and Events
  • Solids Modeling and 3D Printing
    • Subdivision
    • Solids Modeling
    • 3D Printing
  • Vectorworks in Action
  • Archive
    • Resource Sharing
    • Machine Design

Categories

  • Knowledgebase
    • Tech Bulletins
    • Troubleshooting
    • Workflows
    • How To
    • FAQs

Categories

  • Marionette - Objects
  • Marionette - Networks
  • Marionette - Nodes
  • Marionette - Menu Commands

Product Groups

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Occupation


Homepage


Hobbies


Location


Skype

Found 19 results

  1. When using the new irrigation pipe tool, crossing pipes is automatically controlled by an auto-jump feature. The problem is that it automatically creates a gigantic jump. We are very particular graphically. Before the creation of the irrigation tools we precisely created 9" radiused pipe jumps everywhere (depending on graphic scale that dimension can occasionally change). Can we integrate the ability to provide a setting for auto-pipe-jumps to be a specific radius first, and then if we have to change it manually we can? The current process is very time consuming and not at all precise. We have to manually scale every pipe jump and there are no dimensional settings, meaning every single one is slightly different.
  2. One annoying thing I've notice with drip outlets is that Vectorworks doesn't calculate the total drip line lengths when you specify that you want a branching configuration. It seems to be accurate and give a total amount when you specify a snaking configuration, but you end up with "estimated average line length" instead of total line length on branching configurations. This doesn't seem very helpful. Would it be possible to get the total drip line length on branching areas (excluding headers and footers)?
  3. When trying to add a custom valve to the irrigation library, the software fails to recognize fractional sizes. For example, I have tried to create an 1-1/2" version of a valve made by Buckner Superior. When entering the data for size, regardless of whether you enter it as 1 1/2" or 1.5" the library changes that size back down to 1" upon accepting the settings. I have even tried duplicating an existing library instance of a 1 1/2" Rainbird valve, changing a couple of the settings, and then accepting the changes and it still down sizes the valve in the library? Here is a brief video of the problem, sorry for the lack of audio. @LanceF @Tony Kostreski @Eric Gilbey, RLA ASLA @Bryan G.
  4. What is the best way to manage Irrigation Resources in a multi-user environment? We have been making great use of Workgroup Libraries for several years now, but we haven't yet figured out how to collectively manage a library for the irrigation components. Right now, everyone still references the Vectorworks Libraries for the basic "out-of-the-box" irrigation components; however, we often have to add other components to the library. When adding to the library, it seems that this information is only stored in the User Folder and there is no way to store this library in the Workgroup Library for collective use and reference. This means that each user must add each custom component to their library individually, or we have to move the library files around and overwrite each time someone adds something new? That cannot be the intent? Additionally I have noticed that when "Library" files are duplicated to the identical tree in the Workgroup Library, the irrigation tools cannot access them anyway. The only place the menu tools know where to look for irrigation components is in the Vectorworks Libraries location. It would be great if someone could address these issues so that we can effectively build libraries with the irrigation tools in the near future. Otherwise we are just wasting time individually managing libraries. Thanks.
  5. Our workflow for irrigation in VW has ALWAYS been to separate each station into a unique design layer. This allows for greater control, visibility, and conflict detection. Since the creation of the irrigation tools, this workflow has been compromised. Irrigation components, mainly valves, will magically change design layers when connected to different features. Nothing in VW should ever change design layers unless by User Error or by choice. Additionally, when moving valves and other components between design layers, the will actually lose their connection status. I understand that irrigation networks are a unique feature in VW and the fact that they can connect through different design layers in the first place is a revelation, but that shouldn't compromise our ability to control it. The following is a simple screenshare showing the issue. FIX THIS!
  6. When doing a large irrigation system (I'm working on several with over 70 stations), the connection time is incredibly cumbersome and slow. The file I am currently working on takes up to 15 seconds to make one connection. Additionally, we have already turned off the Auto Calculation Update feature, so that is just processing time. Some simple math to show you how cumbersome this actually is... 830 outlets of just one type (over 2000 total in the project) = 830 connections 830 connections at 15 seconds each = 12,450 seconds = 207.5 minutes = approximately 3.5 hours of drafting to make the connections. When compared to our traditional methods, we could do this drafting in approximately 1 hour or less. So for 2.5 extra hours, what do I get? Some data attached to the pipe network? That would be great, except half the time there is at least 1 error for every 20 outlets, which has to be found, diagnosed, and corrected, adding at least another hour to the mix. I get that we are supposed to be moving into the "smarter, not harder" category, but this is only coming at it from the "smarter" perspective while making it a whole lot harder to meet your targets. Expand your horizons Landmark and start thinking bigger than a single, lot residential project. We need BIG applications here that scale easily!
  7. With the new irrigation tools we are still trying to figure out a workflow that streamlines connections on a large job. Unfortunately it is much harder to layout a clean diagrammatic irrigation plan using the new tools since after pipes are created, offsetting lines is no longer an option. Additionally, the process to connect several emitters to lines can is very cumbersome when using the pipe tool and we often experience issues where items become "disconnected" from the network despite the fact that they appear to be connected...blue drop down arrow is present and asks Detach from Pipe Network, despite the fact that the emitter isn't connected to begin with. Perhaps there is a way to create an Auto-Connect command that could be run on selected emitters. This command could automatically draw in connecting lateral pipes to a chosen branch lateral already drawn? Or correct connection error problems by joining to the nearest drafted pipe? Anything to save the headache of troubleshooting connections when your calcs tell you that 5 emitters out of 1000 are not connected properly.
  8. There should be a way to automatically connect an irrigation outlet to any nearby pipe. Since we often work on large complex irrigation systems, our workflow has been to draft irrigation lines as polylines first and get them all correct before converting them into pipes. The reason is that once pipes are created, they cannot easily be replicated through offset methods to show multiple pipes or precise locations. Similarly, we will have often already placed all of our irrigation outlets for the design...thus it would be awesome to select an irrigation head, or multiples, and tell them to auto-connect to the nearest irrigation pipe, or the irrigation pipe of your choosing. THis would autodraw the shortest possible lateral connection in between the outlet and the chosen pipe. I have another very specific workflow example where this would be helpful, but I'll save that for later.
  9. When using the irrigation tools and setting up a P.O.C. or any other piece of equipment, it is possible to query ALL of the PIO fields (i.e. required pressure, greatest zone flow, etc.). This is AWESOME!! HOWEVER!!! I have noticed that pressure values (psi - pounds per square inch) when returned in a database header often do not reflect the correct value! Is this a units issue? See the attached image. RED highlighted values need to equal one another and so do the BLUE highlighted values.
  10. When pipes are created, they cannot be offset by conventional methods. I understand that this request is more complex considering the network character of irrigation pipes, but for graphic clarity on irrigation plans, this is often a must! Sometimes there is a need to convey that several pipes are running along side each other. The cleanest way of doing this is by an offset. To get around this, we have started by creating our pipes using polylines, and offsetting as necessary before Create Objects from Shapes... into pipes (see this post for my separate issue with this command). This works fine until we have to add another pipe or change something and the original functionality is lost.
  11. Another one of those, try, try again until you succeed posts. I posted this awhile ago and included a video, to no avail or answer yet. When using the new irrigation tools, once a pipe is drawn and components are added to it, there is no way to rotate the graphic symbol other than to a true north. What is interesting is that the OIP will show a rotation angle even though the graphic symbol doesn't rotate. You can see the video for a better explanation (sorry, no voice over). https://screencast-o-matic.com/watch/cDX33GQh5g This is really annoying because we almost never get so lucky to work in a true north orientation and our best practice has always been to relate system components and their rotation to the line on which they are placed. It just adds graphic clarity. This problem is also true of any tags or labels that are created from an irrigation object. They cannot be rotated so as to appear horizontal on a sheet layer viewport. This is common practice and I don't understand why the usability hasn't been integrated. We have largely avoided the entire irrigation suite, and this problem is a large reason why. Fix please!
  12. Hi guys, I need some help/clarification, I'm designing an irrigation system with small flower beds (please see the image). Is it correct the way that I'm designing it (connecting different spaces to a single valve)? The program isn't signing any error, but, as it is the first project that I'm developing in VW, I would be grateful for the help. If need, I can upload the file so you can see if I'm not making any kind of mistake. Thank you!! IMAGE.pdf
  13. Hi guys, I'm getting started with Vectorworks Landmark 2017 and I'm developing an irrigation plan where I want to use a root watering system (http://www.rainbird.com/landscape/products/accessories/RWS.htm). I'm adapting it as an emitter since I didn't found this accessory in the library. Did anyone faced this subject? Thanks!!
  14. We have been trying to use the new Irrigation tools in VW2017, but are having some extreme difficulties. On top of the speed issues associated with a network recalculating after every adjustment, we have recently been experiencing repeated crashes while performing what should be basic commands. I have uploaded a screenshot video that shows the workflow and the associated crashes. It seems to happen everytime an object is connected to a pipe (i.e. valve, pipe connection, outlet, etc.) Any help would be greatly appreciated. Thanks. http://screencast-o-matic.com/watch/cDlr0QQtKK
  15. I have only just begun using the irrigtation tools of 2017. I have not been able to rotate irrigation component symbols (i.e. outlet object, valve, system components, etc.) when they are placed on a pipe. I have tried both the rotate tool and entering a rotation value into the rotation input of the OIP and the don't rotate.
  16. When using the new irrigation tools we are trying to determine the best way to share ONE master catalog. We are a multiple station office and need to be all sharing the same resources. The current 2017 installation puts the default catalog on the local C: drive; therefore, every computer has a locally different (albeit the same content) starting catalog. This catalog is extremely extensive, but does not contain ALL of the equipment necessary that we use on a daily basis. Adding catalog data is very straight forward, but the problem I noticed is when a workgroup individual user needs to add equipment to the catalog. This information is stored in separate .txt files in the user folder, but stored separately from any working folder setup. This means that no one else can access the information created by that user without going to the effort of moving and merging that data with the data in the workgroup library. We have a working library that everyone shares, is there a way to move the Master/Default content to that location and then when ANY user needs to add equipment, they add it to the workgroup location and not their individual user folder? Otherwise it seems we have to go through what could be a troubling copy and paste methodology to store the new catalog information. If this functionality doesn't exist, consider this a wishlist request that should be addressed ASAP to allow for larger offices to control the workflow of sometimes complex irrigation catalog information collectively.
  17. Is there a way to turn off the irrigation network updates that occur after every modification to any irrigation object? This update bogs down any changes to a crawl and is almost too cumbersome to handle! Is there a way to turn off the updates or like a worksheet, direct the updates when desired?
  18. I have only just begun using the irrigtation tools of 2017. I have not been able to rotate irrigation component symbols (i.e. outlet object, valve, system components, etc.) when they are placed on a pipe. I have tried both the rotate tool and entering a rotation value into the rotation input of the OIP and the don't rotate.
  19. It is early yet and I am still fiddling with the irrigation tools, but so far...awesome! I did run into one snag. When setting up a drip zone and using a drip control kit with a pressure reducing filter, the calculations for the zone don't seem to account for pressure regulation, just pressure reduction. For example, traditionally my input pressure is 65 psi, but the zone kit would reduce that to an output pressure of 40 psi, no matter the input. In the software, it seems to work that the input pressure gets reduced by 40psi, leaving an output pressure of 25 psi in this example. Not what you want to ensure your calcs come out right. Any ideas?

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...