Follow Background - Slow Readings

[DB-stoutheart]

Is it common for the Background Follow function to really slow readings down? I'm just starting to play with my PID (which isn't going so well), and when I do a follow background its like I'm using a 1990's computer, when in fact I'm using a high performance PC that is also used for 3D Rendering. I've attached a video to show.

https://youtu.be/7-v2eEarRV4

[MAKOMO]

No, this is not common. Most likely there are some communication issues with long timeouts blocking the sampling loop. Are there any errors reported under menu Help >> Messages or Help >> Errors?

Could you try that setup with the current continuous build please: https://github.com/artisan-roaster-scope/artisan/releases/tag/continuous

[DB-stoutheart]

Here is a screenshot of the error window. The version I'm running was downloaded from the continuous builds page yesterday.

[MAKOMO]

Obviously a communication issue.

Could you attach the artisan.log file here (drag-and-drop to the thread on Github, don't answer this email). Note you need to rename artisan.log into artisan.txt!

The log file can be access by holding the OPTION key and a click on the + icon in the upper left corner. This composes an email with the artisan.log file attached.

[MAKOMO]

I just commited a change that removes some experimental code from the Fuji PID connection that I found (all not my code so I am a little lost with all of this and also do not have the device to test). Could you please try the new build? Now the PID background follow will always change the SV0 only (that Fuji PID seems to have a bunch of SV registers). I also disabled the background mode for just logging (ON). It is now only active on recording (after START).

What would also help to enable logging in the Serial console (menu Help >> Serial) as one could see the commands send to the Fuji.

[DB-stoutheart]

I will update to the latest today and do as you have asked with the logging, in the mean time here are the requested log files.

artisan_device.txt
artisan.txt

[DB-stoutheart]

Here are the log files from the latest release. I ran this without beans, but it still lags...didn't see anything in the error window this time.

artisan_device.txt
artisan.txt

[MAKOMO]

Hm. This new log is without any trace of an error and you report there is no error in the error log either. So any communication error seems to be gone now. There were pretty bad errors in the logs for yesterday. Even the Phidget communication failed at one point and the system run out of available file handles. So the whole Mac seemed to be in trouble. Maybe you rebooted the machine in the meantime.

Somethings are still unclear to me about your setup:

• why are you running with a 0.5sec sampling interval. The Fuji is not able to deliver data that fast (no problem for your Phidgets, but you have to care for the slowest device in your setup). Switch this to 1sec or even 2sec!
• why is MODBUS Input 1 active (in the MODBUS tab) but you do not use any explicit MODBUS device (but for the Fuji, but that one is already covered by the main device selection
• why is the MODBUS timeout set to 2sec. I should rather be 0.3sec with a sampling interval of 1 sec. The timeout should always be significant lower than the sampling rate
• why is the serial timeout for the main device (ET/BT tab) as used by the Fuji communication set to 1sec. This should rather be 0.3sec
• why is the MODBUS PID support active (by specifying a slave ID different to 0 in the MODBUS tab in the PID section)? You are using the build-in Fuji PID support and there is no need to activate this here

Please fix the things above and retry first to see if any of this helps

[MAKOMO]

You might also attach your current artisan-settings.txt file as I am looking at the one you shared before which might have changed since.

[DB-stoutheart]

Thank you for the reply. So a lot of the input values that I'm using are based off of the blog posts of Frans and Nico, so I apologize if they're wrong. I'm VERY new to all of this Modbus stuff so I'm doing my best, and I appreciate your help. A few questions for you, regarding your questions. My responses are in bold.

• Why is MODBUS Input 1 active (in the MODBUS tab) but you do not use any explicit MODBUS device (but for the Fuji, but that one is already covered by the main device selection. I was under the impression this was part of the modbus communication. Please help me understand the correct settings within Artisan to utilize the Fuji as the main PID. In the Device Assignment, should Modbus Port be checked?
  -why is the MODBUS timeout set to 2sec. I should rather be 0.3sec with a sampling interval of 1 sec. The timeout should always be significant lower than the sampling rate? Why is the serial timeout for the main device (ET/BT tab) as used by the Fuji communication set to 1sec. This should rather be 0.3sec I left the values at their default, I appreciate you pointing those out to me and I have now changed them
• why is the MODBUS PID support active (by specifying a slave ID different to 0 in the MODBUS tab in the PID section)? You are using the build-in Fuji PID support and there is no need to activate this here. I have read about this, and I'm slightly confused, should all of these values be set to 0 for the Fuji to be the primary PID? If not, is it triggering the software PID within Artisan?

I will make some adjustments and get back to you with as much detail as possible.

Thank you for your time.
Dustin

[MAKOMO]

Artisan features two MODBUS implementations. This thing is a bit wired and caused by the development history of Artisan. Originally (before any public release) Artisan support just the Fuji PXR device. For this the MODBUS protocol was implemented "by hand". Later a generic MODBUS implementation was added which is based on a (now available) Python MODBUS library (pymodbus). With this new generic MODBUS support Artisan did support any MODBUS device incl. other PIDs. However, this implementation lacks all Fuji specifics like direct support for its SV/RampSoak patterns and others.

To connect one of the supported Fuji PIDs one only need to select it in the main device (ET/BT) tab and set its serial communication parameters in the first ports tab (ET/BT).

Later I added the "Modbus Port" flag to wire Fuji PID implementation to the new MODBUS lib bypassing the low-level hand coded MODBUS implementation. So now you can choose which one to use and for the Fuji you will still get the full device support. However, with this flag ticked, the serial parameters of the MODBUS tab are relevant. Most other settings in this tab are not relevant for the Fuji. Especially, the PID section, which should not be used if the Fuji is selected as main device as it gets its specific treatment. That PID section was added to at least support basic features of external pids via Artisans PID dialog.

The software PID is only used if the main device is not a Fuji PID and the slaveID in the PID section of the MODBUS tab is set to 0.

So there are four variants:

• Fuji PID (with specific GUI support in the PID dialog)
• external PID via MODBUS (main device is not Fuji and the slaveID in the MODBUS tab points to the device)
• Arduino/TC4 PID (if main device is a Arduino/TC4 with PID firmware)
• Artisan internal Software PID (if no other PID support is active and Control flag is ticked)

I would start with this setup (and Sampling Interval set to 2sec!):

The setup of Frans is very specific as he is using two MODBUS rings. One using the build-in Fuji support to drive the Fuji PID and SSRs he added to his machine and a second ring using the generic MODBUS support to reach out to the PIDs originally build into his machine to read the temperature values. Additionally he added a bunch of Phidgets...

[DB-stoutheart]

Thank you for the explanation, thats very helpful. Things seem to be running better as of now. I'll need to try another roast before I can confidentely say things are working as they should. I've attached my most recent settings for you to review.

A coupe things I've noticed, if I go into Ports Configuration, every time that window opens, the ET/BT settings window is not maintaining my settings. Two things, Parity always reverts to O, and Timeout always reverts to 1.0. So every time I quit Artisan I go back in and adjust the settings to make sure they're correct.

After playing a bit more, I wanted to follow up on one more thing. I was trying to make some PID adjustments to send to the Fuji, but I noticed that the P-I-D values in the Control window, do not match the P-I-D values on the unit itself, when I click Write pid 1 I noticed its kicking an error out as well...see attached screen shot.

artisan_device.txt
artisan.txt
artisan-settings.txt

[MAKOMO]

Thank you for the explanation, thats very helpful. Things seem to be running better as of now. I'll need to try another roast before I can confidentely say things are working as they should. I've attached my most recent settings for you to review.

Ok

A coupe things I've noticed, if I go into Ports Configuration, every time that window opens, the ET/BT settings window is not maintaining my settings. Two things, Parity always reverts to O, and Timeout always reverts to 1.0. So every time I quit Artisan I go back in and adjust the settings to make sure they're correct.

I cannot duplicate this running the same app version with your settings. There is also no error in the logs you attached since using that latest build. Could you please post a short video sequence demonstrating the issue?

After playing a bit more, I wanted to follow up on one more thing. I was trying to make some PID adjustments to send to the Fuji, but I noticed that the P-I-D values in the Control window, do not match the P-I-D values on the unit itself, when I click Write pid 1 I noticed its kicking an error out as well...see attached screen shot.

As said before, I do not have access to this hardware nor fully understand that code that is not written by myself. However, using my Fuji emulator I cannot duplicate this issue (which does not say much). If I understand the GUI correctly you need to select the SV "bank" using that toggle button, edit the p-i-d values in that row and then press the write button (here labeled "pid 1") in that row to send the changes to the Fuji. Could you please do this with the serial log activated and post what you see?

[DB-stoutheart]

So I couldn't replicate the "Write pid 1" error, but I was able to replicate the Ports Configuration. You'll see I go through the series three times in this video, each time the settings revert back to Parity - O, and Timeout - 1.0.

Screen.Recording.2021-11-30.at.8.33.19.AM.mov

[MAKOMO]

Ondřej, this is a difficult one. The setsv() function sends a "modify SV" command to the Fuji PID and this one answers with an error value in case of the background follow modus. The (manual) SV slider calls the very same function as the background follow mechanism internally. Only difference is that the manual SV slider always calls with an integer while the follow modus calls it with a float. Both, however, are multiplied by 10 and converted to integers before sending them out to the Fuji. I modified the setsv() function to convert its argument to integer in any case, but am not too optimistic that this helps.

Please try the new continuous build.

Some notes on your (complex) setup:

• increase sampling interval to >1.5sec (2 or 3sec) to avoid timing or communication issues. Those MODBUS RTU serial devices are not communicating very fast and you request quite some data.
• decrease serial timeout (ET/BT) from 1sec to 0.4sec. A large timeout will block the communication loop on errors.
• turn curve smoothing significantly down from the (new) maximum 10 to maximal 1
• fix the wrong syntax in button actions:
  • CHARGE (Fuji Command): pidmode2, background => (Artisan COMMAND): pidmode(2)
  • PID1 (Artisan Command): pidmode1 => pidmode(1)
  • PID2 (Artisan Command): pidmode2 => pidmode(2)

[Bouceko]

@MAKOMO Thanks for help. So I'm on the latest continuous build. Now the error/message is Exception: sets(): RX = 0186030261
I've also tried to decrease the serial timeout to 0.4 sec but after clicking OK and reopening this tab, it is back to 1.0.
It is the same problem as @DB-stoutheart had mentioned...

[Bouceko]

@MAKOMO do you have any advice for the Power slider? If i could run at least the slider, it would help.

[MAKOMO]

Thanks for help. So I'm on the latest continuous build. Now the error/message is Exception: sets(): RX = 0186030261

Yes, I added the error value that the device returns (converted to string of integers). Not very helpful either. It is just clear that this communication does not work. Now I wonder why moving the SV slider should work for you as this calls exact the same function. Are you sure that moving the SV slider changes the SV in your device???

I've also tried to decrease the serial timeout to 0.4 sec but after clicking OK and reopening this tab, it is back to 1.0.
It is the same problem as @DB-stoutheart had mentioned...

Ah, now I understand this problem. On closing the Device Assignment dialog the default serial settings incl. this 1.0 sec timeout are set. You can just NOT open the Device Assignment dialog and just open the Ports menu to change the timeout setting until I have fixed this in the next commit.

do you have any advice for the Power slider? If i could run at least the slider, it would help.

You seem to use the MV register number for the Fuji PXG, but as I understand you have a Fuji PXF device. Try to replace the

write(1,41122,{})

by

write(1,42122,{})

[Bouceko]

66561312014__827DA6E6-7308-42BB-AD3C-BC1DE3334D98.MOV

@MAKOMO OK, opening only the Port tab works 👍 I have changed the MV register and will check the function.
I’m posting a video of how the SV slider is changing the value in on the PXF.

[DB-stoutheart]

Another question, how would I set the background follow to use the BT curve rather than the ET curve?

[MAKOMO]

The Fuji PID setup can only follow the signal it is reading. This is different when using the Software PID where one can select any signal.

[DB-stoutheart]

Thank you

[Bouceko]

Very interesting stuff is happening when using the Power slider. It actually sends the value to the PXF but the Fuji immediately get’s back to the value calculated from the set SV. Maybe this could be helpful. It looks like the SV slider has some kind of priority.
https://user-images.githubusercontent.com/98848822/152427400-45093d65-06f9-4a01-9b0e-0963bebe4509.MOV

[MAKOMO]

Well, of course as long as your PID is ON (active) it will calculate its p-i-d function and set the MV (power slider) based on the current target SV. You need to turn the PID inactive to be able to use the power slider manually.

[Bouceko]

Yep, that was exactly what I thought off. Recently, it doesn’t work on my config. Eventhough the PID is turned off, I change the value on the Power slider, it shows the value on the FUJI and immediatly goes back to the original value.

I’m so sorry for this long disturbtion, but I’m getting to the end of my possible knowledge :-)

[Terracotta-19]

Yes, that's exactly what I thought. Recently, it didn't work on my configuration. Even if the PID is turned off, I change the value on the Power slider, and it displays the value on FUJI and immediately returns to the original value.

i'm sorry for this long interruption, but i'm approaching the end of my possible knowledge :-)

Refer to Discussion #879 settings to control the output power of the power supply，hope to help you！