I’m having an issue with the latest release, I can’t get either Ladybug or Honeybee to fly, when I drop the base component onto the workspace it freezes up and I have to kill the process.
I have updated to latest Grasshopper and python, anything basic I’m missing?
I’m only a novice user but managed very easily to get the last one up and running!
How long have you waited for the process to run before you kill it? Copying LB_KB and HH_HB usually take several seconds now that we have added a lot more classes and functions that take time to copy to the menory.
It’s taking upwards of 4-5 minutes, so I was wondering if something was wrong. Sounds like something might be up then if it’s only meant to take several seconds?
I’m hopefully getting a PC upgrade in a few days so I’ll be able to compare. It should be a fresh install of Rhino/GH/LB+HB so that might fix things up as well.
Hnn. This is an interesting case. If your Rhino, Grasshopper and GHPython are all up to date then you are not missing anything basic. Keep me posted about what happens on your new machine.
Is that the case both for Ladybug and Honeybee? Ladybug shouldn’t take long at all to load. In case of Honeybee the first time that you let it fly, it downloads a number of files that you can find in installation folder. I wonder if that is the reason of 4-5 minutes?
It is the case for both. I was thinking it could have been an issue with attempts at downloading. I’m stuck behind a rather strict corporate firewall.
I noticed that Openstudio_standards.json was one file that was attempted and blocked, so I got a copy of that downloaded separately. Still no fix. Are there more specific files that are needed?
If I can get the firewall relaxed for an initial run should this fix it up for good?
I’m not sure if firewall is the reason since Ladybug doesn’t download anything once you let it fly. Is that also the case when you insert other GHPython components into canvas?
Let us know if changing your system didn’t solve the issue. There might be something strange going on with copying data to sticky.
Not really related to your issue but in case you don’t know, once you let them fly you will be fine for that instance of Rhino and you don’t need to do it again.
Thanks for the help guys, much appreciated. I think it’s my system and will know for sure when my new one arrives. A colleague who hasn’t updated HB/LB only take a few seconds.
Out of curiosity. are you able to drop the normal GHPython component in the Maths tab onto your canvas? That will give us an idea if it is something specific to LB+HB or something that more generally happens with GHPython on your system.
I am able to drop it on without any issues. Of course it has a warning that I have no script to execute!
One thing that Honeybee says after it has run is that Schedule = OA already is existed in the library, please rename on of the OA. What does this mean?
Hopefully my new system will be around this week to test.
Sorry for taking so long to get back. I can tell you what the error means: the component is saying that the schedule for Outdoor Air (OA) is already in your openStudio library. So my guess something is going wrong in the download of the OpenStudio libraries that automatically happens when you drag and drop the HB component onto the canvas the first time.
What is your internet connection like on your machine? Is is stable? Is there a firewall or anything that could block your access to the site app.box?
There is a workaround for this if this is so. You will have to download the openstudio libraries here:
and then copy and paste them into a folder that you create in this location of your computer:
C:\ladybug\openstudio
If there is a folder there already, then delete it.
My guess is that something similar might be happening for Ladybug and the Radiance functions that it downloads and uses. I can give you more instructions if this first workaround helps.
My internet connection is behind a corporate firewall and very difficult to get around, so I agree it could be an issue here.
Unfortunately the openstudio files downloaded and placed in the spec’d location didn’t have an effect.
It did however highlight for me that not all content is defaulting to c:\ladybug. Model results seem to go between that location and the appdata\roaming folder for ladybug instead. I copied the openstudio files into there as well, but no luck.
Now, which is even stranger, my GH file asks for HB and LB to be flown even after the file has initialised (346.7 seconds…), so I have to delete and re-drop them onto the canvas.
All very strange, and my colleague who is running an older version of HB and LB doesn’t have these issues.
Last but not least, these issues are happening on my new system as well.
Thanks for all the help, let me know anything you ned from me to help identify what this could be!
From the what you describe and re-reading Mostapha’s comments, it sounds like it is an issue with copying things to the memory of your system (or the “sticky” that Mostapha mentioned). I attached a file that has a GHPython component that just copies stuff to the memory and another that reads it back. Let me know if you are able to open the and get a number in the panel in the file. If not, this may be a question that we need to field to the makers of GHPython.
I have been getting another error with HB, my gh canvas has the most recent HB and LB elements on it, but even after opening and the 366 second initial calc time, some of my HB elements require that I let HB fly again.
Ben - The warning is because of the order of execution of components in Grasshopper. If you disable/enable the components with warning they will work fine. To avoid the issue next time that you open the file select Honeybee_Honeybee component and press ctrl+B so it will be executed before other components next time you open the file.
Also can you try the attached file and let me know if it runs normal. There is a version check that tries to download a file from dropbox and I wonder if that is causing the issue.
that file runs in 3 seconds, so it’s definitely the firewall blocking the dropbox connection. I checked the HB update module and it also doesn’t work for the same reason.
Cool. It is just that your company’s firewall just blocks background downloads from dropbox. Mostapha, do you think that we could put in a check to not download the files if someone has done so manually, as Ben seems to have done?
Thanks for reporting Ben. It should be an easy fix then. I added the issue to github and we will get it fixed soon. Meanwhile you can use the Ladybug component with no version check.
I can’t see Chris’s comment here but based on what I have in my email, the component won’t download the files every time. This is a version check and happens every time so it will notify the user if a newer version is available. I can add a time-out so if the connection is blocked it just passes the test.