When I execute the node the progress bar jumps to 30% after which the error is given.
In the knime.log I found this:
2021-01-22 08:28:20,345 : ERROR : KNIME-Worker-20-R to Table 0:743:0:705 : : Node : R to Table : 0:743:0:705 : Execute failed: Could not parse REXP.
org.knime.r.controller.IRController$RException: Could not parse REXP.
Caused by: org.rosuda.REngine.REXPMismatchException: attempt to access org.rosuda.REngine.REXPGenericVector as String
… 18 more
Any idea why this node worked before, but now runs in an error?
In my case it was df$days_count <- work_days_count(…). But in function I typed “return(result[i])” instead of “return(result[[i]])”. It was OK for R data.frame but not OK for KNIME table. Maybe you have similar problem.
Thanks for your input! R is less picky on what is allowed. Maybe the data frame which I put in this knime.out is not allowed anymore? As mentioned I used the workflow before in Knime 4.1.3 and there it was all okay.
Maybe it’s the third column in my dataframe which is causing the problems.
I have this “R to Table” node in other places in my workflow and there are “model” and/or “Month” returned without problems.
My bet: this “signal” column is the most likely cause. It is a list.
Let’s see what the Knime-experts think of it.
Edit: I removed this signal column in the knime.out and now the node finishes normally. So it’s the list in a data.frame which is triggering this error.
Indeed very brutal
Since this all came from a workflow in which timeseries are forecasted, I would definitely have to deal with these strings, the dates and the values contained in the signal are pretty meaningless when they are just strings. I hope a proper solution becomes available too.
The node which worked is the one shown at the top. I cannot share this workflow due to confidentiality, but in essence is it the same as in the example: I calculate a model using ARIMA() and forecast() for the prediction. This result is to be converted to this R to Table node to a Knime table.
My desktop is migrated, so I cannot replay the old situation. I used the workflow often before this migration. Whether it’s W7 to W10 or Knime 4.1.3 to 4.3.0 or both I can’t say. I haven’t thought on making a copy first…
Somewhere I hope there had been a change in Knime which can explain this. Maybe I have to change my ARIMA forecast component and split this signal column into separate values. It will be a job for monday when I’m back at work.
From something I added in the description of my component I have the impression this signal column contained these two numbers before as well. Somehow the R to Table node just took the first column from the list, which contains the signal.
It’s only circumstancial “evidence”, but as said I cannot replay this old situation anymore.
Under Windows10 I’m using R 3.6.3 and RServe 1.8-7 which is the latest you get when creating it from source. I used RTools 3.5 to compile this RServe.
Initially I created RServe 1.8-6, but that gave these issues in the first place. That’s why I attempted this newer version, but that did not make any difference. I kept this newest version.
Under Windows7 I’m sure about the version of RServe: 1.8-6. I followed the instructions in this post of @mlauber71 which I mentioned earlier in this topic. When I compiled it almost two years ago this 1.8-6 was the newest version.
I’m not 100% certain on the R version (and I cannot check it anymore). This was either 3.6.1 or 3.6.3 as well.
In combination with Knime 4.1.3 it worked great.