Hi,
I am experiencing problems with a new version of PC400.
Old one is v1.5 with compiler CR1000.Std.16, CompileDate: 081029
New one is v4.0 with compiler CR1000.Std.21, CompileDate: 100922
My sources have not changed at all.
Compiled with the old one: No problem, gets compiled in pipeline mode, runs smooth as ever.
Compiled with the new one: BIG problem, gets compiled in sequential mode, slow scan skips are piling up...
What has changed?
Any work around?
Or better a bugfix?
Alle helpis highly appreciated, thanks in advance,
Henry
The compiler in the PC software does not make any difference to the program that runs in the logger (except in the case of CR200). The compiler on the PC is really only a check tool, although the errors it reports match those that will normally be returned by the datalogger.
What you need to check is the operating system in the datalogger. It recompiles and runs the program not the software on the PC.
Are you using different datalgogers with the different versions of PC400?
Hi,
two CR1000, same sources running on them.
The newer one compiles the sources in sequential mode, the older one compiles in pipeline mode.
The exact version numbers can be posted mid next week -> the older CR1000 is already installed on a ship, the newer one is in my lab beeing prepared.
But I have to postpone everything as the system is not stable due to the problem with the newer compiler...
So same as with the PC compilers.
Newer one compiles differently as the older one.
What has changed?
Henry
More details:
Newer CR1000:
OSVersion: CR1000.Std.21
OSDate: 100922
OSSignature: 55356
SerialNumber: E2054
RevBoard: 017.008
Older CR1000 should have the version 16 installed.
16: all fine, sources get automatically compiled in pipeline mode.
21: not good at all! sources get automatically compiled in sequential mode.
Henry
Hello Henry,
You can attempt to force a program to compile in PipeLine mode, using the PipelineMode instruction at the beginning of the program. Note, however, that a program usually defaults to SequentialMode because of the programming structure. For instance, measurement or control instructions placed within conditional statements will force the program to SequentialMode. These should be pointed out by the precompiler if you attempt to compile something that the datalogger would consider "illegal".
Regards,
Dana W.
Hi Dana,
I know that I can force the compiler to Pipeline mode but would consider that "quick and dirty".
There must be a reason why one compiler does it this way and the other compiler does it another way.
And currently it looks as if the new versions turned to the wrong direction as it results in less stable systems.
Is there a chance to downgrade the CR1000 to version 16 compiler as workaround until the fault in the newer compiler has been found?
Thanks,
Henry
For all dataloggers but the CR200, the precompiler in the CRBasic editor is merely a syntax checking tool. The actual compilation takes place in the datalogger; thus, you can always load an old OS back into the datalogger.
In general, however, the newer OSes are more stable and have new features, so I would review carefully the OS revision history on our web site to make sure you aren't causing more problems than you solve by downgrading the OS.
It's likely that the older precompiler/OS were not doing a check that should have been done. The newer OS has the check added, and thus the change in compilation behavior. In reality, the newer OS might be a better measurement/more stable than the old, even though from your perspective the older OS is "better".
It's hard to tell since the program has not been provided. Perhaps if you wish to pursue this further you should contact Customer Support of whichever Campbell Scientific office serves your geographic location so specific questions can be addressed.
Dana W.
Hi,
I pinched the problem down to using SerialOutBlock which I have to use once because I need to send 00hex via one serial to our connected DCP.
Within the new help it says:
> This instruction normally runs sequentially from the
> processing task sequencer, regardless of whether the
> datalogger is in pipeline or sequential mode.
Ok.
That would explain why the CR1000 switches to automatically to SequentialMode.
But:
> However, when running in pipeline mode, if the
> COMPort parameter is a constant set to Com1, 2, 3,
> or 4 and NumberBytes is a constant, the instruction
> will run from the measurement task sequencer.
In my case the com-Port is set fixed to com2 and NumerBytes is fixed to 1.
So why does the CR1000 still switches to SequentialMode although PipeLineMode shouldn't be a problem at all here?
Henry
Do you have the Serialoutblock instruction within an IF statement OR in a subroutine called from an IF statement (or similar conditional construct). If so this will force sequential mode. This was made to happen in revision 18 of the OS, because it caused a serious issue in some circumstances. Serialoutblock and Serialinrecord are designed to run in the measurement (highest priority and tightly time controlled) sequence, when in pipeline mode to allow precision timing of the collection of data from some serial sensors.
One characteristic of measurements in pipeline mode is you cannot branch around them otherwise it would break the consistent timing of subsequent measurements.
There may be some trick to work around this but we'd need to see your program to advise further.
Hi Andrew,
here is roughly what I have done:
SlowSequence
Scan(1,Sec,5,0)
' [...]
If TimeIntoInterval(50,60,min) Then
SerialOutBlock(com2,CHR(00),1)
' [...]
EndIf 'of TimeIntoInterval
NextScan
If you don't mind I'll send my complete code to you tomorrow by mail?
Thanks in advance,
Henry
As the command is in a slow sequence (which has secondary priority) and we know the cause for it switching to sequential mode, you could just try forcing the program into pipeline mode to get back to where you were.
I would advise checking that the chr(0) is transmitted when you think it should be, i.e. once at 50 mins into 60 mins.