This tutorial contains GIF images.
If they fail to load please visit the help center via web browser.
You can zoom this page with Ctrl+.
Currently there are two possible ways as to how tables are generated on a terrain and what their height is in PVcase:
- Generation without enabled terrain tolerance.
- Generation applying terrain tolerance.
Generation without enabling terrain tolerance.
In the first case, the tables both for fixed-tilt & trackers are placed at a minimum distance to the ground. This minimum distance to the ground is described using the Frame height by lowest point input. The important thing to understand is that by specifying this number you're not only describing the height by the lowest point but also the height for the entire frame based on this point.
When PVcase is generating without the applied height tolerances (the 1-st approach) it is placing all of the frames to be at least this input distance from the ground.
Which means, for the front side it is at least 800 and for the back side upper point it is at least 2534 mm. for instance. So if there's a hill in the middle of the frame - it is elevated to meet the minimum distance requirement.
An example of this can be seen below in a front view:
Using no terrain tolerance can result in height differences between adjacent tables which in turn can cause shading and impact a PVsyst near shading scene export. In order to reconcile this issue - terrain tolerance needs to be enabled.
Generation applying terrain tolerances.
In this second option - when we start using terrain tolerances we can change the way that this height is being handled by allowing the frame to be placed closer to the terrain. This in turn can cause tables to collide with the terrain and increase project ground grading costs but reduce pole lengths.
When we enable Terrain tolerances this opens up the inputs for Allowed hill under frame and Allowed ditch under frame and Ditch radius from pole.
With the Allowed hill size under frame input you can specify what size mounds/hills underneath the frame are acceptable. For instance if I input an allowed hill of 0.2m. this would mean that all of the tables that could be placed do not get closer to the terrain than by 0.2m.
In the example above we can see that the table cannot be placed if a hill is exceeding the allowed size input. Therefore once we generate PVcase will only place the tables that are eligible for placement. If we turn on indicative frames the tables that get too close to the terrain will be color coded (default color - orange).
With PVcase you're also able to identify how many tables cannot be placed due to a ditch underneath the table by inputting an allowed size in Allowed ditch under frame.
The main difference between hill and ditch checking is that ditches are checked from the predefined poles in a table.
For instance, if we have a table with a ditch of 0.5 m. and our Allowed ditch under frame is set as 0.4m. and the checking radius from each pole is set as 2.5m - PVcase will place the table since the distance from the pole to the ditch is too small.
If we increase the radius from the pole to a bigger value - the checking distance will reach the ditch underneath and will not place the table.
So, when generating a layout PVcase will only place the tables that are eligible for placement and meet the ditch checking requirements both by distance from the poles and the size of the ditch.
PVcase can indicate frames that could not be placed do to this reason if Ditch tolerance indicative frames are enabled.
- After having set these values the user is able to identify which tables have poles that do not exceed the allowed length of poles. Then, one is able to extract these value using Pole coordinates and BOM export.
- By preseting these values you're able to also identify how many tables or how much project capacity is impacted by terrain obstacles.