¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

D3 Data files.


 
Edited

I made an update to the scheduled events.? I connected with toolbox and noticed that the updated files were loaded outside of the NVRAM\D3_Pro folder and that the old files were still inside the NVRAM\D3_Pro folder.? Looking at the simpl program, it appears that this is a D3 change to the file load location.


 

D3 will always use \\NVRAM\\scheduler.dat as the file path in SIMPL.
On 2-Series this corresponds with the location \NVRAM\scheduler.dat
On 3-Series/4-Series this corresponds with the location \NVRAM\D3_Pro\scheduler.dat

This is because 3Ser/4Ser have 10 program slots; NVRAM is split into subfolders.
The path \\NVRAM\\ in SIMPL corresponds with \NVRAM\<ProgramIDTag\ on the processor.

Recent Toolbox releases may be having some intermittent issues with D3 .dat file uploads.
BR 8236 was reported against?TB v3.1250.0002 & Toolbox team is actively investigating this.
("D3 - Scheduler - /D3_Pro/ Subfolder Creation & .DAT File Not Consistently Uploaded to Internal NVRAM")


 

Great Info.? Both processors are 4 series and when I did updates in August, they were uploaded to D3_Pro folder in NVRAM.? Today with the latest updates, the files were loaded to the root NVRAM.? I used toolbox to copy them into D3_Pro folder as well.? Being that tweaks for this project are pretty much always remote, I wanted to check to make sure that the schedular files had updated.? That is when I saw that they had been loaded to the root and the old files were still in the folder.


 

I created a case with TB today.? I am manually loading the updated files to the NVRAM\D3_Pro folder after load of the program.


 

Have you guys noticed if the scheduler is actually working? I have a new job where the client is really into the scheduler and it seems to stop working. Its just a regular D3 program in a standalone cp4. I can edit the schedule in the panel as usual but when I change the time of the processor to trigger an event it doesnt. It tested fine 2 days ago, but today its not.


 
Edited

I have a D3 project running on a PAC2 using a CF card. I just did a small update to the program having nothing to do with scheduling and now the scheduled events are not running.
Last change was over a year ago.
- The schedule file is in the Compact Flash A/Scheduler folder
- The NVRAM folder has nothing in it, no even a D3_Pro folder.? ?(And it won't let me create one)

I don't have any PAC2 projects that I can compare it to.

Dave, can you update this situation? it seems like I should have the D3_Pro folder...
My Versions are:
D3Pro is v3.05.001.00
TB is v3.1250.0002.0??
CresDB is v
219.05.001.00
DevDB is v
200.280.002.00


 
Edited

You need to roll back to CresDB 212.00.002 to get the scheduler to to work per??

Just really baffles me why they wont fix this. Yea I know 2 series is no longer supported blah blah, but there has to be thousands or tens of thousands of 2 series lighting systems that are out there running perfectly with uptimes in the years value that a simple schedule change should still be possible without playing DB games.?


 

So I rolled back the CresDB and recompiled. I'll know tonite if the schedules are working (I'm only 3.5 hrs away from the site...)
I'm concerned that the Scheduler file is still in the CF/Scheduler folder not the NVRAM. Of course this could be because of the CF but I don't know. Anyone know if this sounds right?

Also, here's the official response to my case:
"This case was brought to management's attention and I apologize for any inconvenience but the information that was provided to you from the Application Engineer is the official stance of Crestron.? You will need to roll back to the DB mentioned in the Online Help Article with either a dedicated PC or a VM instance to be able to correctly compile D3 programs with scheduled events for the 2 series processor."
....The way I read this is that Crestron says its not their problem anymore...:(


 

I rolled back the crestron db and recompiled using D3 (PAC2 processor) and the scheduled events still failed to fire. I opened up SIMPL Debugger and saw that by default the scheduler was in Suspend_FB. I traced the Suspend signal and it only went to a buffer with 0, so its not me putting the scheduler in Suspend. I ended up using a trigger 1 minute after startup in D3 to send the Enable Scheduler command (for good measure) followed by the Resume Scheduler command.


 

Good to know Casey, though we *shouldn't* need to do that...
I'm really ticked as what seems like Crestron's attitude of 'All you dealers/programmers, just set up a VM for each and every issue that we don't want to deal with...'


 

So Casey just doing this startup trigger is all thats needed to fix this and not a database juggle? I guess thats alot easier. That would also indicate the issue isnt the scheduler module itself or a 2 series limitation to me. Just something broken in the convoluted way D3 generates all that logic.??


 

Holiday lighting schedule issues from clients are killing my weekend.? Trying to figure out who at Crestron I need to send my bill to.
In meantime, my personal X10 system circa 1990 is hitting nice every time.


 
Edited

So I just had this scheduler thing bite me again, with a 4-series this time (apparently I'm too old to regularly remember 753 different bug work-arounds )
am I right in understanding this issue?
a. 2-series requires rolling back DBs
b1. 3/4-series requires either triggering the enable for the scheduler on start - AND/OR -?
b2. manually create \D3_Pro\ folder in \NVRAM and?move the scheduler.dat to this folder

I don't have remote access to the site , but when I loaded the program on my test CP4, it didn't even create the D3_Pro folder, let alone load the Scheduler.dat file...
And yes, I said to load the scheduler file on upload...

Thoughts?


 

Update: I updated my software about a week ago (DBs, TBx, D3, SMW) and this seemed to fix the schedule.dat file being properly loaded/updated to the NVRAM/D3_Pro folder as expected.

I also see that there are new DBs and TBx updated as of 2/27/24 where the TBx notes indicate that the Schedule.dat fix is done (It seemed fixed before this) so we have that going for us!...